Re: Smart --with-package=DIR (for absentminded users)

[Benoit SIGOURE]

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