This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
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 Makefile.am \) -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
configure.in/Makefile.am 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
complex).
> 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