Can I build gcc so -Wall option is always on ?

[Joel Dice]

On Sat, 9 Jan 2010, Joel Dice wrote:

> On Sun, 10 Jan 2010, Dr. David Kirkby wrote:
>
>>  Ralf Wildenhues wrote:
>> >   Hello David,
>> > 
>> >   * Dr. David Kirkby wrote on Thu, Dec 24, 2009 at 05:38:23PM CET:
>> > >   I'm helping on the Sage maths project
>> > > 
>> > >   http://www.sagemath.org/
>> > > 
>> > >   where there are a large number of packages built, most of which 
>> > >   ignore CFLAGS. (Quite a few ignore CC and CXX too!) I'd like to 
>> > >   display all the warnings, but its hard when people overwrite CFLAGS.
>> > > 
>> > >   Is there a way I can build gcc such that effectively "-Wall" is 
>> > >   enabled all the time?
>> > 
>> >   I hate to be stating the obvious, but why not use a wrapper script?
>> > 
>> >   mv gcc gcc.real
>> >   cat >gcc <<\EOF
>> >   #! /bin/sh
>> >   exec gcc.real -Wall "$@"
>> >   EOF
>> > 
>> >   or just put one early in your $PATH.  Depending on your needs, it might
>> >   have to be a bit more complex (put -Wall at the end if you care about
>> >   overriding -Wno-all and some other flags, for example; or only add 
>> >   -Wall
>> >   if -c is also seen, or similarly).
>> > 
>> >   Cheers,
>> >   Ralf
>> >
>>  I've tried this, and it works in 90% of cases, but not all. 'sqlite' is
>>  once such package which always gives errors if I try to build like this.
>>  The errors are like "no newline" or something like that. So I stuck a new
>>  line in, but it still does not work.
>>
>>  Here's one such error, where
>>
>>  make[2]: Entering directory
>>  `/export/home/drkirkby/sage-4.3.1.alpha1/spkg/build/sqlite-3.6.19.p0/src'
>>  if /bin/sh ./libtool --tag=CC --mode=compile gcc -DPACKAGE_NAME=\"sqlite\"
>>  -DPACKAGE_TARNAME=\"sqlite\" -DPACKAGE_VERSION=\"3.6.19\"
>>  -DPACKAGE_STRING=\"sqlite\ 3.6.19\"
>>  -DPACKAGE_BUGREPORT=\"http://www.sqlite.org\" -DPACKAGE=\"sqlite\"
>>  -DVERSION=\"3.6.19\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1
>>  -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1
>>  -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1
>>  -DHAVE_DLFCN_H=1 -DHAVE_FDATASYNC=1 -DHAVE_USLEEP=1 -DHAVE_LOCALTIME_R=1
>>  -DHAVE_GMTIME_R=1 -DHAVE_READLINE=1 -I. -I.   -I
>>  /export/home/drkirkby/sage-4.3.1.alpha1/local/include
>>  -DSQLITE_THREADSAFE=1 -Wall -g -m64 -m64  -g  -O2  -MT sqlite3.lo -MD -MP
>>  -MF ".deps/sqlite3.Tpo" -c -o sqlite3.lo sqlite3.c; \
>>  	then mv -f ".deps/sqlite3.Tpo" ".deps/sqlite3.Plo"; else rm -f
>>  ".deps/sqlite3.Tpo"; exit 1; fi
>>  mkdir .libs
>>  gcc "-DPACKAGE_NAME=\"sqlite\"" "-DPACKAGE_TARNAME=\"sqlite\""
>>  "-DPACKAGE_VERSION=\"3.6.19\"" "-DPACKAGE_STRING=\"sqlite 3.6.19\""
>>  "-DPACKAGE_BUGREPORT=\"http://www.sqlite.org\"" "-DPACKAGE=\"sqlite\""
>>  "-DVERSION=\"3.6.19\"" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1
>>  -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1
>>  -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1
>>  -DHAVE_DLFCN_H=1 -DHAVE_FDATASYNC=1 -DHAVE_USLEEP=1 -DHAVE_LOCALTIME_R=1
>>  -DHAVE_GMTIME_R=1 -DHAVE_READLINE=1 -I. -I. -I
>>  /export/home/drkirkby/sage-4.3.1.alpha1/local/include
>>  -DSQLITE_THREADSAFE=1 -Wall -g -m64 -m64 -g -O2 -MT sqlite3.lo -MD -MP -MF
>>  .deps/sqlite3.Tpo -c sqlite3.c  -fPIC -DPIC -o .libs/sqlite3.o
>>  gcc: 3.6.19": No such file or directory
>>  make[2]: *** [sqlite3.lo] Error 1
>>  make[2]: Leaving directory
>>  `/export/home/drkirkby/sage-4.3.1.alpha1/spkg/build/sqlite-3.6.19.p0/src'
>>  Error making sqlite
>
> Try replacing the "$@" in your script with ${1+"$@"}.  That should ensure 
> "-DPACKAGE_STRING=\"sqlite 3.6.19\"" appears as a single argument to 
> gcc.real.

Replying to my own suggestion, I'll mention that the ${1+"$@"} syntax is 
something I found in a script written by someone else, and I suggest it 
because I've used it with success in similar situations.

However, despite having studied the man pages for several shells, I have 
never actually figured out what ${1+"$@"} means and how it differs from 
just "$@".  Indeed, the "$@" syntax seems perfectly adequate for this 
case, so I can't explain why Ralf's suggestion isn't working.  I've just 
run a few simple tests, each of which behaves the same regardless of which 
syntax I use, so perhaps they're interchangeable.

Perhaps a shell programming expert can enlighten us.

>>  (The two -m64's are a result of it being added elsewhere too, but
>>  generally I've not found a wrapper suitable.)
>>
>>  Dave
>> 
>> 
>
>