Hi Steve,
I'm afraid that applying this patch upstream *does* have a portability
impact; the patch will do the right thing on systems that use the GNU linker
or a linker with similar features, but there are other Unices that don't
support dynamic linking or whose library format doesn't store dependency
information, so on these systems a hardcoded -lImlib2 won't work. Also, not
all GNU/Linux systems put libImlib2 in the linker search path, so
imlib2-config --libs may output -L values needed for linking.
I admit I have forgotten about local installation and such, which was
dumb. As for static linking, I had a good look at enlightenment CVS, and
this seems never to be supported anyway by imlib2-config, as you
suspected, so it is not a direct issue (I do not restrain nor extend
portability by ignoring the case -- it's a known limitation).
From your comments, things are now done a little differently[1]: I added
code to first try to link a demo Imlib2 program with the "-lImlib2"
switch, then I fall back reusing the output of "imlib2-config --cflags
--libs" when it doesn't work. This way, people with a ld or similar
linker and Imlib2 in their default library path will not depend directly
on outdated freetype and such as long as this is possible, while things
should continue to work without side effects for everyone else the way it
was before.
As for the rest of your patch (AM_MAINTAINER_MODE, no X Extra, distcleans
targets, etc.), I think it is all good and should stay in too. Let me know
if you see any other problems with the updated scripts... Yours,
--
Sylvain <[EMAIL PROTECTED]>
Garbage In -- Gospel Out.
[1]http://adesklets.sourceforge.net/cgi-bin/gitweb.cgi?p=adesklets.git;a=commit;h=903e3fdef4790afb65a82b9632e563cf8640e162
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
