[GRASS5] Re: [GRASS-CVS] CVS update: grass

Glynn Clements glynn.clements at virgin.net
Thu Aug 2 23:05:43 EDT 2001


GRASS wrote:

> I have much trouble with new configure too. With this one, I can not find many
> headers and libs without options though I didn't have any problem finding
> them before. Of course those files are in a standard directory(?). Anyway,
> what's the standard directory?
> 
> 	/usr/include, /usr/X11R6/include, /usr/local/include?

It depends upon the compiler and/or linker.

For the X headers and libraries, configure will attempt to determine
the necessary parameters using Imake if the user didn't specify
--x-includes and --x-libraries.

> And there is a typo in configure*.

Yep; I know. Thanks for fixing it.

> I don't know why wandering for required files is not good.

Because configure simply doesn't have enough information to make that
kind of decision.

The main reason for not allowing configure to add directories of its
own accord is, if any of those directories contain a header file which
conflicts with a required header, the entire build process falls
apart, and the only solution is to manually edit files.

A specific example is the case where configure was adding
-I/usr/include, resulting in an incompatible version of stdarg.h (I
think) being used instead of the (correct) version from
/usr/lib/gcc-lib/<platform>/<version>/include.

> It's more convenient and more simple(not for programmers but for
> USERS). I think we'd better focus on users' convenience. Am I wrong?

Having to explicitly specify directories is a minor inconvenience.
Having to debug the build procedure because configure decided to break
it by adding bogus -I or -L switches is a major inconvenience.

Basically, it's trivial to extend the list of directories which are
searched, but impossible (by normal means) to reduce it. Consequently,
the more directories which are searched automatically, the more likely
that the build will fail regardless of what configure switches are
used.

-- 
Glynn Clements <glynn.clements at virgin.net>



More information about the grass-dev mailing list