setting compiler flags (was: Re: any way to set an automake variable in a top-level automake file, and have it apply to subdirs?)

[Ed Hartnett]

Ralf Wildenhues <address@hidden> writes:

> I just would not mumble with AM_CFLAGS at all, unless necessary.  If the
> user hasn't specified CFLAGS, the configure script will try to enable
> one or both of "-O2" and "-g" (both if they work together).  As a user,
> I can override it by setting CFLAGS appropriately.  As a package author,
> I'd only override it in case there are compilation errors without or
> with a certain option.  However, even in that case there are good
> arguments _against_ doing so:  you (as a package author) have no idea
> when a certain compiler bug for example may be fixed.  Also, there is a
> plethora of different compilers and systems out there.

Howdy Ralf!

The library I'm distributing is netcdf, a scientific data package, and
it's very popular on a huge variety of platforms, all over the
world. To add to the porting challenge, it's got a C, F77, F90, and
C++ API, and tests in all those languages.

Previous to the current release, we followed the approach you outline
above, in which the user was responsible for setting any "weird" flags
needed for their particular combination of compiler bugs, OS stupidity,
etc. 

This generated a TREMENDOUS amount of support email. Way too
much. Basically, every user would have to email us to figure out their
flags, and someone here would have to tell them what to use. (Users
are all Earth scientists, not computer scientists!)

With the most recent release (3.6.0) I changed the configure script to
automatically set flags for our five or six most popular
platforms. (Sun, AIX, Mac, etc.). This seems to have reduced support
email quite dramatically. 

(Also, it's very nice for users to just run the configure/make
commands and have everything work out of the box. I must assume that
for every user that contacts me with an install question, there are
others who just give up and use something else.)

In my next release, 4.0, there is an explosion of flag settings, due
to our combination with another library (HDF5). In this (upcoming)
release I also include a configure option --disable-flag-setting,
which the user can use to turn off all these attempts to set compiler
flags. Then he is on his own.

This is the compromise I've stuck. Do you think it's a good approach?

And thanks for all the help. You are assisting in the study of the
global climate, which is certainly one of our greatest computational
challenges!


Ed


-- 
Ed Hartnett  -- address@hidden