eliminating CFLAGS

[Andy Dougherty]

On Mon, 8 Feb 2010, Will Coleda wrote:

> When we build parrot now, we generate CFLAGS from
> config/gen/makefiles/CFLAGS.in during Config.

> Now, I can envision a system where we move this entire decision making
> process into config time, so it's rendered in the generated makefile,
> so that there is (as now) a default .c rule with the standard CC
> flags, and then individual makefile rules for those files which have
> changes to the CC flags. We don't need syntax for additions, since we
> can simply add them, but we could make something like @ccflags:
> -Wcast-qual@ work.

> My question is: is it necessary for us to jump through these hoops?
> Most of the directives in CFLAGS.in are to quiet a noisy build. The
> most complicated turn off optimization in some or all cases. What's
> the bare mininum we need to support here, e.g. is breaking out the
> optimize flag sufficient? Is having a build with no warnings worth

Perl 5 uses a similar sort of mechanism.  In perl 5's hints/ directory, a 
quick grep indicates 54 uses of this mechanism, of which 35 are related to 
optimization.  Applied to parrot, I'd expect breaking out the optimize 
flag would cover most of the cases for now, but it would be useful to not 
preclude the possibility of adding or subtracting other flags.  (In 
general, I have found it useful to be able to do things like "make 
OPTIMIZE=-g" in the build directory without having to re-run Configure.pl, 
so I think breaking out the optimizer flags is probably a good thing in 
any case.)

>                           Is having a build with no warnings worth
> jumping through hoops for?

Last time I checked on gcc/SPARC, the parrot build had nearly 4,000 
warnings. It's hard to see how a few more would make any real difference.
 
> Also, our current build process masks the actual command line used
> during the build, showing a dummy version before we start; as we make
> this script go away, we'll end up just using a regular build that will
> show the build for each step. As it is, we cannot look at a build and
> see how a particular file was built, since the script is hiding what
> it's doing.

I have never liked that either, but my last patch to change it was 
rejected.

-- 
    Andy Dougherty		doughera at lafayette.edu