Re: AM_C*FLAGS and C*FLAGS
The trick is that if we use a configure.ac file to help decide what flags may be needed, >inside< this configure script we need to use CFLAGS and CPPFLAGS to effect the running of configure. Not really. Just AC_SUBST a variable in the AM_CFLAGS or AM_CPPFLAGS directive. E.g., when I write an autoconf macro to link against an optional library, my Makefile.am's usually end up having stuff like this in them: Makefile.am for foo that optionally depends on bar: AM_CFLAGS=-I../otherdir @BAR_CFLAGS@ bin_PROGRAMS=foo [EMAIL PROTECTED]@ if BAR foo_SOURCES += bar-dependent.c endif Then, at configure time, the CFLAGS, the "always-on" AM_CFLAGS, and the "optionally-on" AM_CFLAGS are all respected as configured. If you want to see an example of an autoconf macro that provides this kind of substitution, I have one here: http://andre.stechert.org/urwhatu/2006/04/autoconf_macro_.html Cheers, Andre smime.p7s Description: S/MIME cryptographic signature
Re: AM_C*FLAGS and C*FLAGS
> On Mon, 2006-06-26 at 04:34 +, Harlan Stenn wrote: > > We are told that we should not use CPPFLAGS or CFLAGS in a Makefile.am, > > as they are for users. > That's only partially true. > > More precisely: You should not override user-supplied CPPFLAGS, CFLAGS, > CXXFLAGS, LIBS etc. > > Appending something to these vars would be OK, provided the > user-provided settings "always win". And how, exactly, is that supposed to work? If we supply values for *FLAGS, how does the user easily keep those and append their own? > > The trick is that if we use a configure.ac file to help decide what > > flags may be needed, >inside< this configure script we need to use > > CFLAGS and CPPFLAGS to effect the running of configure. > Depends on what you add to *FLAGS. Please elaborate. For (possibly bad) examples, once upon a time I was told by developers that in order have a successful 'configure' run and to build The Software on: - i386-sequent-sysv4 that we needed to have CFLAGS+= -Wc,+abi-socket (please excuse the shorthand) - *-*-mpeix that we need: CPPFLAGS+="-DMPE -D_POSIX_SOURCE -D_SOCKET_SOURCE -I/SYSLOG/PUB" (and LDFLAGS+="-L/SYSLOG/PUB" and LIBS+="-lcurses") - *-next-nextstep4: CFLAGS+=-posix On more recent/normal issues, there are other cases where we may be pointed at "local" installation areas for OpenSSL, which would require feeding an override for -I and -L to the remainder of the configure script and also passing these values into the Makefile. Exactly how do you propose this be done? > One standard approach would be to use *FLAGS as package-global FLAGS and > AM_*FLAGS as per-Makefile.am FLAGS, i.e. not to AC_SUBST(AM_*FLAGS) > inside of a configure.ac, but set up AM_*FLAGS inside of each > Makefile.am anew from other AC_SUBST'ed vars to provide more > fine-grained control over FLAGS. Which is useful to some projects, I expect, but not mine... Again, if *FLAGS (I assume you mean CFLAGS, CPPFLAGS, LFLAGS, etc.) are set in configure and propagated to the Makefile's, how does the user override these without doing a lot of typing? H
Re: AM_C*FLAGS and C*FLAGS
On Mon, 2006-06-26 at 04:34 +, Harlan Stenn wrote: > We are told that we should not use CPPFLAGS or CFLAGS in a Makefile.am, > as they are for users. That's only partially true. More precisely: You should not override user-supplied CPPFLAGS, CFLAGS, CXXFLAGS, LIBS etc. Appending something to these vars would be OK, provided the user-provided settings "always win". > The trick is that if we use a configure.ac file to help decide what > flags may be needed, >inside< this configure script we need to use > CFLAGS and CPPFLAGS to effect the running of configure. Depends on what you add to *FLAGS. One standard approach would be to use *FLAGS as package-global FLAGS and AM_*FLAGS as per-Makefile.am FLAGS, i.e. not to AC_SUBST(AM_*FLAGS) inside of a configure.ac, but set up AM_*FLAGS inside of each Makefile.am anew from other AC_SUBST'ed vars to provide more fine-grained control over FLAGS. How to handle this inside of a configure.ac is up to you and depends on your package's demands. The big pitfall inside of all this trying to setup optimization flags. In general, these should not be under a configure.ac's control, but under user control. My recommendation is not trying to setup optimization flags. Ralf
AM_C*FLAGS and C*FLAGS
We are told that we should not use CPPFLAGS or CFLAGS in a Makefile.am, as they are for users. The trick is that if we use a configure.ac file to help decide what flags may be needed, >inside< this configure script we need to use CFLAGS and CPPFLAGS to effect the running of configure. (I say CFLAGS adn CPPFLAGS, but I have a possibly incorrect memory that for configure tests, they all need to be in CFLAGS.) Assuming this is true (ie, I am not mistaken), how can one make these "choices" in a configure script and then "decompose" these choices so that: - the right values end up in AM_CFLAGS and AM_CPPFLAGS - CFLAGS and CPPFLAGS are empty in config.status H
