This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: #pragma optimization_level

[Cc: list drastically trimmed.]

On Tue, 5 Apr 2005, Marcin Dalecki spake:
> On 2005-04-05, at 01:28, Nix wrote:
>> On 4 Apr 2005, Marcin Dalecki stipulated:
>>> I don't agree with the argument presented by Geert Bosch. It's even more difficult to
>>> muddle through the atrocities of autoconf/automake to find the places where compiler
>>> switches get set in huge software projects
>> What's so hard about
>> find . \( -name 'configure.*' -o -name \) -print | xargs grep CFLAGS
>> anyway?
> Tha fact the you actually *seldomly* have the precise version
> of autoconf/automake/perl/gawk installed on the host you wont to reproduce the
> THRE stages to get a hand and Makefile.

The GNU toolchain has become a little more automated in the last, oh, five years:
`autoreconf && configure' will do the trick.

I've found that the combination of autoconf-2.59, automake-1.9.x and
libtool-1.5.10 can handle all but the most complex combinations, even those intended for much
older versions of autoconf and not updated: the only ones that I haven't
locally upgraded are for XEmacs and GCC (both of which are fearfully

> I could turn the question back: What's so hard about grepping the source?

Because one does not expect to find compilation flags embedded in the
source?  Because generated source is fairly common? Because eventually
that runs you into `what's so hard about predicting the behaviour of
this code generator in order to...' and then you ram straight into
the halting problem, or, worse, Qt's qmake program. :)

(None of these are strong arguments, I'll admit, but if your argument
*for* is `it's convenient', then an argument *against* of `it's
unexpected' is stronger than it looks.)

>>  A few minutes will suffice for all but the most ludicrously
>> byzantine project (and I'm not talking `uses automake', here, I'm
>> talking `generates C code in order to compute CFLAGS to use when
>> compiling other code'.)
> Thus by your definition most projects are byzantine. glibc, tetex ans
> so on...

teTeX -> plain autoconf, automake. No difficulties (there used to be
some back in the teTeX-1.x days, so I fixed them and submitted patches).

gcc -> exceptionally complex, but you frotz with CFLAGS here at your
peril (I do it, but I'm a risk-taking lunatic).

glibc -> definitely byzantine and unique, but when you get down to it
autoconf + ordinary Makefile (if a very, very complex one). Plus, all
the expected ways of globally overriding CFLAGS work there: you can set
CFLAGS and LDFLAGS in the environment, on the configure command line,
and in site-config files, and glibc will carefully override just those
parts that conflict with particular files when needed.

Actually, glibc is a good argument *against* the need for this feature:
it has a large number of places where unusual one-off CFLAGS are
required, and it manages to do them all via one-file overrides in the
makefiles. See e.g. linuxthreads/sysdeps/i386/Makefile for an extensive
use of this. csu/Makefile has an example of *completely* overriding the
CFLAGS for a single file that is especially delicate (initfini.s).

I think this feature would be convenient in some circumstances,
principally to work around places where optimizations turn into
pessimizations for specific compiler versions in speed-critical code:
but the difficulty of changing CFLAGS in makefiles isn't a good reason
for it. :)

This is like system("/usr/funky/bin/perl -e 'exec sleep 1'");
   --- Peter da Silva

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]