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
