[PATCH modular 2/3] build.sh: support CC, CPP, CPPFLAGS and CFLAGS

[Gaetan Nadon]

On Fri, 2010-12-03 at 05:59 -0800, Dan Nicholson wrote:

> > +  CC          C compiler command
> > +  CFLAGS      C compiler flags
> > +  LDFLAGS     linker flags, e.g. -L<lib dir> if you have libraries
> in a
> > +              nonstandard directory <lib dir>
> > +  CPPFLAGS    C/C++/Objective C preprocessor flags, e.g. -I<include
> dir> if
> > +              you have headers in a nonstandard directory <include
> dir>
> > +  CPP         C preprocessor
> >   CONFFLAGS:  additional flags to pass to all configure scripts
> >   CONFCFLAGS: additional compile flags to pass to all configure
> scripts
> >   MAKEFLAGS:  additional flags to pass to all make invocations
> 
> If we're picking these up from the environment, then why do we need to
> pass them to configure?

I struggled with this question as I noticed it in the current
implementation.

I vaguely recall Automake recommending specifying it on the command
line, though they make every effort to ensure it works properly.

It makes it clearer at the top of config.log: 

  $ ./configure --prefix /home/nadon/xorg/src CFLAGS=-g3

The requirement comes from Timothy Meade. He is building X for an arm
processor, so I thought it would perhaps be better in a cross-compile
scenario which I don't fully understand.

I could not find any reason for not including it on the command line.


> 
> > @@ -348,7 +355,14 @@ process() {
> >     if [ $needs_config -eq 1 ] || [ X"$NOAUTOGEN" = X ]; then
> >        sh ${DIR_CONFIG}/${CONFCMD} --prefix=${PREFIX} ${LIB_FLAGS} \
> >            ${QUIET:+--quiet} \
> > -           ${CACHE:+--cache-file=}${CACHE} ${CONFFLAGS}
> "$CONFCFLAGS"
> > +           ${CACHE:+--cache-file=}${CACHE} \
> > +           ${CONFFLAGS} \
> > +           ${CC:+CC=}${CC} \
> > +           ${CPP:+CPP=}${CPP} \
> > +           "${CPPFLAGS:+CPPFLAGS=}${CPPFLAGS}" \
> > +           "${CFLAGS:+CFLAGS=}${CFLAGS}" \
> > +           "${LDFLAGS:+LDFLAGS=}${LDFLAGS}" \
> > +           "$CONFCFLAGS"
> 
> Should CC and CPP not be quoted? It's quite common that people want to
> run CC="gcc -m32". Also, I'm not sure I understand why the brace
> expansion is used like this. Typically people keep the whole
> expression inside the braces:
> 
> ${CFLAGS:+CFLAGS="$CFLAGS"}

I spent some quality time in quoting hell. I tested CFLAGS with "-g3
-O0" but I assumed CC and CPP would be a single word which is wrong. So
I'll fix this.

> 
> The way the quoting is being used now, you'll end up with a bunch of
> empty arguments to configure. E.g., if LDFLAGS is empty, the whole
> expression will expand to "".

I will try this out. I followed the existing "$CONFCFLAGS" pattern

> 
> Sorry to ask one more question, but doesn't CFLAGS conflict with
> CONFCFLAGS?
> 

Yes it does, that's why it is removed from the public user interface in
the next patch.

The core role of build.sh is simply to invoke ./configure on a large
number of packages. Along the way more and more options, flags or what
not have been added to build.sh for propagation to all packages. The
script has grown its own "proprietary" interface which the user has to
map to the autoconf interface. This patch attempts to replace this
proprietary interface with the autoconf package  interface so the user
does not have to learn 2 interfaces.

I appreciate very much your review.




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.x.org/archives/xorg-devel/attachments/20101203/8d1a9365/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg-devel/attachments/20101203/8d1a9365/attachment-0001.pgp>