[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Smart --with-package=DIR (for absentminded users)
From: |
Benoit SIGOURE |
Subject: |
Re: Smart --with-package=DIR (for absentminded users) |
Date: |
Fri, 6 Jul 2007 09:07:01 +0200 |
On Jul 6, 2007, at 8:32 AM, Thomas Lavergne wrote:
2. How can I detect that /path/to/foo helps in any way for
accessing foo.h and libfoo.a? Specifically, if library foo is
available in the system directories (e.g. /usr/include and /usr/
lib), then providing --with-foo=yes and --with-foo=/wrong/path/to/
foo will have the same effect.
However, your input does not exactly answer the concerns I
expressed in my original question 2) :-).
Which is that library foo (foo.h and libfoo.a) might exist in two
or more locations on the machine. And it might very well happen
that one of these versions resides in the 'system' directory for CC
(e.g. /usr/{include,lib}). In that case '--with-foo' is enough to
pass all your (and mine) previously introduced tests. Always in
that case, --with-foo=*/wrong/path/to/lib* will still pass our
tests (using the same default/system version of foo). That is
because CFLAGS and LDFLAGS, when 'useless' (or 'wrong'), have no
effect on CC and LINKER (at least for gcc). Specifically, the user
might give --with-foo=/home/loginname/local/ (thinking foo.h is in /
home/loginname/local/include) but his version of foo is in fact
installed in /home/loginname/local/foo/ (foo.h being in /home/
loginname/local/foo/include/).
So... any idea?
PS: I know my user should NOT have a local and modified version of
foo with the same file names and same version number. In my case he
does AND provides a /wrong/path/to/lib at configure time. We might
as well damn him and let him rot in hell. But we might as well not,
if possible.
Alright so if /wrong/path/to/lib is a non existent path, it will be
error'ed out by configure.
Now if the path exists but does NOT contain anything related to
libfoo AND libfoo is installed under /usr/{lib,include} then I see
several ways out:
1. Use something like -nostdinc during your tests to prevent the
compiler from searching in its default include directories.
I think this has the disadvantage of being compiler dependent (which
might not be a problem right now if you only target GCC but most
people try avoid that).
2. You seem to imply that the version of libfoo under /usr/
{lib,include} is different then the one you require (hence configure
would succeed but the build would fail)
In this case your tests must try to make sure that the libfoo that
has been found (no matter where it has been found) works for you,
that is, that it has been compiled with the required features, that
it is at least the minimum version you want and so on.
To do this the best way is to try to find something discriminant
among the different versions of libfoo that would help you to tell
whether the version configure found is the good one. Many libraries
install a header that #defines a FOO_VERSION or FOO_VERSION_
{MAJOR,MINOR}.
If you require version 2+ of libfoo, you can try to compile a small
program that uses a symbol introduced in version 2. If libfoo can be
compiled with optional features, make sure you also try to compile
small test programs that use these features.
3. If the user passes a wrong path to --with-foo=DIR (although the
path itself exists) *and* the compiler can find the correct version
of libfoo in its standard paths, then the build will succeed but the
user won't know that they gave a wrong argument to configure.
Well there is nothing much you can do here I'm afraid but at least
the build worked.
Hope this help.
Cheers,
--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory
PGP.sig
Description: This is a digitally signed message part