<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN"> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8"> <META NAME="GENERATOR" CONTENT="GtkHTML/3.26.0"> </HEAD> <BODY> On Fri, 2010-12-03 at 05:59 -0800, Dan Nicholson wrote: <BLOCKQUOTE TYPE=CITE> <TT>> +  CC          C compiler command</TT> <TT>> +  CFLAGS      C compiler flags</TT> <TT>> +  LDFLAGS     linker flags, e.g. -L<lib dir> if you have libraries in a</TT> <TT>> +              nonstandard directory <lib dir></TT> <TT>> +  CPPFLAGS    C/C++/Objective C preprocessor flags, e.g. -I<include dir> if</TT> <TT>> +              you have headers in a nonstandard directory <include dir></TT> <TT>> +  CPP         C preprocessor</TT> <TT>>   CONFFLAGS:  additional flags to pass to all configure scripts</TT> <TT>>   CONFCFLAGS: additional compile flags to pass to all configure scripts</TT> <TT>>   MAKEFLAGS:  additional flags to pass to all make invocations</TT> <TT>If we're picking these up from the environment, then why do we need to</TT> <TT>pass them to configure?</TT> </BLOCKQUOTE> 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: <PRE>   $ ./configure --prefix /home/nadon/xorg/src CFLAGS=-g3 </PRE> 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. <BLOCKQUOTE TYPE=CITE> <TT>> @@ -348,7 +355,14 @@ process() {</TT> <TT>>     if [ $needs_config -eq 1 ] || [ X"$NOAUTOGEN" = X ]; then</TT> <TT>>        sh ${DIR_CONFIG}/${CONFCMD} --prefix=${PREFIX} ${LIB_FLAGS} \</TT> <TT>>            ${QUIET:+--quiet} \</TT> <TT>> -           ${CACHE:+--cache-file=}${CACHE} ${CONFFLAGS} "$CONFCFLAGS"</TT> <TT>> +           ${CACHE:+--cache-file=}${CACHE} \</TT> <TT>> +           ${CONFFLAGS} \</TT> <TT>> +           ${CC:+CC=}${CC} \</TT> <TT>> +           ${CPP:+CPP=}${CPP} \</TT> <TT>> +           "${CPPFLAGS:+CPPFLAGS=}${CPPFLAGS}" \</TT> <TT>> +           "${CFLAGS:+CFLAGS=}${CFLAGS}" \</TT> <TT>> +           "${LDFLAGS:+LDFLAGS=}${LDFLAGS}" \</TT> <TT>> +           "$CONFCFLAGS"</TT> <TT>Should CC and CPP not be quoted? It's quite common that people want to</TT> <TT>run CC="gcc -m32". Also, I'm not sure I understand why the brace</TT> <TT>expansion is used like this. Typically people keep the whole</TT> <TT>expression inside the braces:</TT> <TT>${CFLAGS:+CFLAGS="$CFLAGS"}</TT> </BLOCKQUOTE> 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. <BLOCKQUOTE TYPE=CITE> <TT>The way the quoting is being used now, you'll end up with a bunch of</TT> <TT>empty arguments to configure. E.g., if LDFLAGS is empty, the whole</TT> <TT>expression will expand to "".</TT> </BLOCKQUOTE> I will try this out. I followed the existing "$CONFCFLAGS" pattern <BLOCKQUOTE TYPE=CITE> <TT>Sorry to ask one more question, but doesn't CFLAGS conflict with CONFCFLAGS?</TT> </BLOCKQUOTE> 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. </BODY> </HTML>