how to handle a gui- and non-gui-version of the same library/soname
Monday, January 18, 2010, 2:27:22 PM, you wrote:
> is there any good way how to handle the situation described at
> I.e. you have a single library (single soname) which can be compiled
> with or without GUI support (with different ABI) -- and we'd like to
> have both of them, of course -- the non-GUI version on headless servers,
> the GUI one for desktop.
> As far "yelling at upstream" sounds like the most correct way.
I'd suggest that the proper solution would be to separate the GUI
functions into a separate library with a separate-but-related soname,
and have that library depend on the non-GUI library.
That way the final GUI tools would depend on both libraries, and the
equivalent command line tools only on the non-GUI library.
If possible, common functions should use shared code hosted in the non-GUI
library. Otherwise you could get different results from the slightly
different code in the two libraries. These lead to "it works if I do it by
A1, but fails with A2" bug reports.
>From this user's POW, it gets more insane if A1 and A2 are the same tool
that supports running in GUI and command line modes.
devel mailing list