joel.sherrill at oarcorp.com
Mon Feb 8 22:01:37 UTC 2010
On 02/08/2010 12:57 PM, Andrew Whitworth wrote:
> 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.
Since we (RTEMS folks) want Parrot on RTEMS don't forget
that cross-builds often will have to specify flags for CPU
model. We will add "-BBSPDIR/ -specs bsp_specs -qrtems" on
every compile line. This adds a directory to the system
path for the compiler that is board specific and augments
gcc's rules with bsp_specs.
I am all in favor of simplification and faster builds. We
are happy if it is computed once and kept, as long as it
can be set. :)
> --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.
>> Will "Coke" Coleda
More information about the parrot-dev