eliminating CFLAGS

Will Coleda will at coleda.com
Mon Feb 8 17:33:15 UTC 2010


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

Then, at run time, every time we compile a C file, we run a perl
script, passing in the entire command line that would be invoked as
args. That script parses CFLAGS (every time cc would be invoked) to
see if there are any additions/subtractions or modifications to be run
that match the file we're compiling.

This works out to about 2% of the build time on a relatively fast unix
system. I can only imagine it's worse on a windows build (but haven't
benchmarked it there.)

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
jumping through hoops for?

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.

Thoughts?
-- 
Will "Coke" Coleda


More information about the parrot-dev mailing list