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. :)
--joel sherrill
RTEMS
--Andrew Whitworth
On Mon, Feb 8, 2010 at 12:33 PM, Will Coleda<[email protected]> 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
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
