autoconf
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: environment variable conventions


From: Olaf Weber
Subject: Re: environment variable conventions
Date: Thu, 02 Sep 2004 21:02:11 +0200
User-agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux)

David Lee writes:

> I am working on a project in which the end-user's configure would like to
> ensure that certain items appear in autoconf output variables such as
> CPPFLAGS.  We have received a query from a user whose routine "configure"
> usage at his site not a simple "./configure" but rather is of the form:
>     CPPFLAGS="..."  ./configure

> How should the incoming CPPFLAGS (from the user's environment) normally
> interact with any being set in "configure".  My guess is that configure's
> CPPFLAGS should modify (prepend? append?) any setting from the environment
> rather than simply replace it.

> But presumably in the case of "CC", the operation would be a simple
> replacement.  What about CFLAGS, LDFLAGS etc.?

> Are these principles documented somewhere?  In neither the autoconf manual
> nor the "GNU Autoconf, Automake and Libtool" book did I find anything but,
> of course, I may well have missed it, so a pointer would be fine.

The rules I prefer are as follows:

The standard variables CC, CFLAGS, CPPFLAGS, LDFLAGS ... will normally
have appropriate defaults generated by the configure script.

If they are specified during the configure run, then these values
replace the normal configure-generated defaults.  This I need because
configure will set CFLAGS to '-O2 -g' if the compiler doesn't complain
too loudly, but non-gcc compilers often just switch off optimization
when this combination of flags is seen (with the MIPSpro compilers on
IRIX, for example, you'd need to use '-O2 -g3' to get debuggable
optimized binaries).

When running make you have another oppurtunity to override them, and
you can completely replace them.  This I find again mainly useful to
change optimization and/or debugging without having to re-run the
configure script.

This typically means that you have to redefine the compilation rules
in the makefile, for example like this:

CCcompile = $(CC) $(DEFS) $(INCLUDES) $(CPPFLAGS) $(CFLAGS)

.c.o:
        $(CCcompile) -c $<


In this case, DEFS and INCLUDES are set by the configure script and
contain the additional defines and includes that configure finds are
needed to compile the package.  In contrast, CPPFLAGS and CFLAGS can
be overridden as described above.


This is at least tocuhed on in the automake manual, in "Variables
reserved for the user".  So automake automatically generates a whole
lot of machinery to make all this work.  (But as I don't use automake,
I've no idea whether all the cases I care about are handled in the way
I'd like them to be handled.)

-- 
Olaf Weber

               (This space left blank for technical reasons.)





reply via email to

[Prev in Thread] Current Thread [Next in Thread]