Re: Library dependencies

[Jonathan Gapen]

Nicola Pero wrote:
> But there is a little point we probably need to think about before doing
> any change of this kind - some exceptional gnustep applications could need
> to access the support libraries directly.  For example, exceptional
> gnustep applications could need to use gnustep-gui and still in
> exceptional cases access X directly.  For all of this to work, the X
> library used by gnustep-gui and the X library used by the application need
> to be the same.  The same applies, say, to libxml.  If you build an
> application which both links with gnustep-base and uses libxml directly,
> then you must use and link with the same libxml that is used in
> gnustep-base.  This can only work easily if gnustep automatically passes
> -I, -L, -l flags for all support libraries when compiling/linking - that
> is, the old arrangement.  How can we make a rearrangement which is
> flexible enough to meet both needs ?

    I look at it this way:  Currently, you must configure the GNUstep
libraries to use the same versions of libraries that your existing
executables were linked against.  If you want to use an updated library,
you must re-compile *all* of your GNUstep executables.  This is a
serious case of the tail wagging the dog.  If you get pre-compiled apps
from various sources and the versions of the libraries they were linked
against don't all match, you're SOL.  You just can't configure the
GNUstep libraries to depend on multiple different versions of libraries,
unless we extend the library-combo to some monstrosity like
gnu-gnu-gnu-xgps-staticobjc-noffcall-noiconv-xml2-gmp-nossl, and that's
just unworkable.
    Now, considering the case of a program that needs the same libraries
as a GNUstep library, I divide them into two cases:  1) the app that
needs a library *because* the GNUstep library does, and 2) the app that
needs a library regardless of whether the GNUstep library needs it.
    With the new scheme, case 2 is easy: the programmer should provide
the link flag in the GNUmakefile.preamble and not count on the GNUstep
library flags, given that most GNUstep library dependencies are
optional.  Then if the user should happen to update to a new version of
a library, both the GNUstep library and the app contain a dependency,
and the user needs to update the two of them.  (All other GNUstep
executables are unaffected.)
    In case 1, the programmer needs to know quite a bit more information
than just the link flags to build an executable that's tied to a GNUstep
library internal implementation.  For example, that program that uses
gnustep-gui and X needs to know well before the link stage whether the
GUI backend uses X at all, and the programmer must account for that. 
Therefore, I think it not much of an imposition on the programmer to
have to either specify the link flags manually, or add an additional
line such as "ADDITIONAL_LDFLAGS += $(GNUSTEP_BACKEND_LDFLAGS)" to the
GNUmakefile.preamble.  In this case, both the GNUstep library and the
executable depend on a certain library, so the user must update both
when updating that library, but with the additional caveat that the user
must update the executable if the GNUstep library implementation
changes.  Still, this is a far cry from the need to update *every*
executable when a GNUstep library's dependencies change.
    So I've gone off on a big tangent here, but I'm hoping to point out
that a huge increase in flexibility for the GNUstep user is worth the
loss of a bit of flexibility for a few GNUstep programmers.  (And it's
not much of a loss of flexibility if the programmer has to merely ask
for the linker flags for the support libraries instead of getting them
automatically, n'est pas?)