eliminating CFLAGS

[Joel Sherrill]

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<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
>>
>>      
> _______________________________________________
> http://lists.parrot.org/mailman/listinfo/parrot-dev
>