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).
Hmm, I'm rather surprised at the notion that static linking isn't
supported; the build targets certainly build a static version of
libImlib2 by default.
I was stunned too: static version of the library is built by default, but
just plainly ignored *in all cases* by imlib2-config generated out of
imlib2-config.in. Maybe I missed something... I will ask on
enlightenment-devel if I do not find the answer myself.
Well, could still give the wrong results if the user has multiple copies
of imlib installed and wants to build against a version other than the
one in the default search path; but that's certainly an edge case,
perhaps one not worth worrying about.
I thought of that, but if the user is sophisticated enough to manually
keep various versions of libraries around, I assume he is probably aware
of such risks, and certainly able to run a dynamic library check (ldd or
similar) to notice what he uses aftwerwards. I am aware ignoring
imlib2-config and similar pkg-config scripts is not the usual behavior of
an autoconf script, and that's why I added an explicit warning in the
configuration output.
My main concern is that if upstreams adopt library-handling patches that are
intended to be Debian-specific and in the process break compatibility with
other systems, we'll have a harder time in the long term convincing others
to adopt solutions that *do* work for everyone. :) The check you describe
seems to be ok in this regard.
I acknowledge that. As you initially pointed out, this would be better
solved right into imlib2-config... But Imlib2 is not my codebase, and
Carsten Haitzler has already job for ten years beyond the grave; I
will see if I can swing a patch his way or something anyway...
Yours,
--
Sylvain <[EMAIL PROTECTED]>
Every program is a part of some other program, and rarely fits.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
