eliminating CFLAGS

Will Coleda will at coleda.com
Tue Feb 9 13:29:01 UTC 2010

On Mon, Feb 8, 2010 at 8:03 PM, Andy Dougherty <doughera at lafayette.edu> wrote:
> On Mon, 8 Feb 2010, Will Coleda wrote:
>> 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?
> Short summary:
> The optimzation hoops are necessary -- especially since rakudo's
> --gen-parrot option automatically calls --optimize. Without the
> optimization hoops, an optimized build will break on gcc/amd64, and
> possibly cause non gcc compilers to crash with an out-of-memory error on
> the big core ops files.
> The warnings hoops are not *necessary*.  Even with them, the build is
> generally not warning-free.  However, given that some mechanism must be in
> place to remove the optimization flags for certain files, it would seem to
> me to be appropriate to consider whether that mechanism could be
> generalized (at only moderate cost) to also remove warnings flags for
> certain files.
> --
>    Andy Dougherty              doughera at lafayette.edu

Ok. I've started down this path in the rm_cflags branch - it already
has removed the perl script; I'd appreciate some tests on something
other than gcc/gmake. I broke out the 2 files that added flags and
those are done, and dropped several cases from CFLAGS where the
warnings that were prevented don't occur any more.

All that's left is to add the mechanism for manipulating @flag@ at
interpolation time. Syntax suggestions welcome (for a little while,
anyway. =-)


is my current thought - we only need a way to specify a change, since
that syntax covers addition/removal also.

Will "Coke" Coleda

More information about the parrot-dev mailing list