Mo DeJong <[EMAIL PROTECTED]> wrote:
>On Thu, 6 Jul 2000, Steven G. Johnson wrote:
>> Because of this, I think it is a good idea to document at least LDFLAGS
>> ("-L/somedir/lib") and CPPFLAGS ("-I/somedir/include") in the --help,
>> perhaps along with CC/CXX/F77 and CFLAGS/CXXFLAGS/FFLAGS. I wouldn't mind
>> submitting a patch for that.
>
>How would you know what directory /somedir is?
?? That's the whole point--configure has no way of knowing this, which is
why the user has to specify it in some way. The user knows because she is
either the one who installed the libraries in question or has access to
that information (e.g. by asking the sysadmin or by looking in the
documentation for the system or site).
I'm just saying that the --help message should educate users that there is
a standard way to specify library directories. (And yes, people do look in
the --help...I've had users try to use --libdir to specify library
directories, for example, not knowing about LDFLAGS and being confused by
the --help string.)
Or are you just asking how to explain this in the help string? Probably
/somedir/lib is a bit too abbreviated even for --help, but I was just
trying to quickly explain what I was referring to.
>I could see that it
>might make sense to check for ${prefix}/include and ${exec_prefix}/lib
>and use those as a default if they exist (and perhaps if they are
>not the "regular" default like /usr/local). That way if you have
>three packages that want to install into /usr/mydir, and all three
>use the same --prefix, then it will just work like magic.
That's a really nice idea, although you would have to provide a way to
disable this for the perverse case that there were files in $libdir or
$includedir that you don't want to see...I just have a twinge of worry
because this isn't entirely backwards compatible. (Actually, even
-L/usr/local/lib might be a good idea if that is the $libdir, since some
compilers don't look there by default.)
This is separate from the question of what should go in --help, though
(which would still be needed since this only covers one possible case,
albeit a common one).
>But then again, you could just code that into your own configure.in.
You could, but I don't think that developers should have to do such things.
This is a general problem of software installation and is not specific to a
particular program. Having each package try to solve it in its own way is
not really desirable.
Steven
