eliminating CFLAGS

Andrew Whitworth wknight8111 at gmail.com
Mon Feb 8 18:57:52 UTC 2010

I'm pretty strongly in favor of this change. Having more information
available about how individual files are compiled is always a good
thing. %2 improvement on build times isn't itself a motivating factor,
but a more straight-forward build process is.

--Andrew Whitworth

On Mon, Feb 8, 2010 at 12:33 PM, Will Coleda <will at coleda.com> wrote:
> 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
> _______________________________________________
> http://lists.parrot.org/mailman/listinfo/parrot-dev

More information about the parrot-dev mailing list