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 <[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
