eliminating CFLAGS

[Will Coleda]

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

[Andrew Whitworth]

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

_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev

[Andy Lester]

On Feb 8, 2010, at 11:33 AM, Will Coleda wrote:

> Is having a build with no warnings worth
> jumping through hoops for?

Yes yes yes, but it's no surprise that I would be the one to say that.

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

That's always bothered me, too.

xoxo,
Andy

--
Andy Lester => an...@petdance.com => www.theworkinggeek.com => AIM:petdance

_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev

[Andy Dougherty]

On Mon, 8 Feb 2010, Will Coleda wrote:

> When we build parrot now, we generate CFLAGS from
> config/gen/makefiles/CFLAGS.in during Config.

> 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

Perl 5 uses a similar sort of mechanism. In perl 5's hints/ directory, a
quick grep indicates 54 uses of this mechanism, of which 35 are related to
optimization. Applied to parrot, I'd expect breaking out the optimize
flag would cover most of the cases for now, but it would be useful to not
preclude the possibility of adding or subtracting other flags. (In
general, I have found it useful to be able to do things like "make
OPTIMIZE=-g" in the build directory without having to re-run Configure.pl,
so I think breaking out the optimizer flags is probably a good thing in
any case.)

> Is having a build with no warnings worth
> jumping through hoops for?

Last time I checked on gcc/SPARC, the parrot build had nearly 4,000
warnings. It's hard to see how a few more would make any real difference.

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

I have never liked that either, but my last patch to change it was
rejected.

--
Andy Dougherty doug...@lafayette.edu
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev

[Austin Hastings]

Coke++; idea++;

1. Having a quiet build is worth a lot.

2. Having an honest build is worth a lot.

3. Recomputing CFLAGS on the fly every time is stupid. Put it in the
makefile, and recompute it under the same terms that the Makefile gets
rebuilt.

=Austin

_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev

[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

_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev

[Jonathan Leto]

Howdy,

> 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

This is a great point, Joel. I also believe that striving for a
warning-free build is worth the effort, but we need to make sure we
are not winning a Pyrrhic Victory [0] but losing the maintainability
war. If we have to introduce a few warnings for a short time while we
figure out a new, better, config system, then I am not against that.

[0] http://en.wikipedia.org/wiki/Pyrrhic_victory

--
Jonathan "Duke" Leto
jona...@leto.net
http://leto.net
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev

[Andy Dougherty]

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.

[Chris Johns]

On 2/9/2010 9:01 AM, Joel Sherrill wrote:
> 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.

If Parrot builds tools on the host require to build the target code
there needs to be 2 separate sets of flags. Does it ? Typically
HOST_CFLAGS handles the host and CFLAGS handles the target. This also
goes for CC where HOST_CC handles the host compiler and CC is the target
compiler.

Chris
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev

[Will Coleda]

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. =-)

@cc_warnings:s/-Wno-unused/unused/@

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

[Will Coleda]

On Mon, Feb 8, 2010 at 7:46 PM, Chris Johns <chr...@rtems.org> wrote:
>
> On 2/9/2010 9:01 AM, Joel Sherrill wrote:
>>
>> 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.

This can be done by passing a parameter to Configure.pl - see the
--help on that for adding CFLAGS.

> If Parrot builds tools on the host require to build the target code there
> needs to be 2 separate sets of flags. Does it ? Typically HOST_CFLAGS
> handles the host and CFLAGS handles the target. This also goes for CC where
> HOST_CC handles the host compiler and CC is the target compiler.
>
> Chris
> _______________________________________________
> http://lists.parrot.org/mailman/listinfo/parrot-dev
>

We don't go out of our way to support cross-platform compilation at
the moment; we don't use HOST_CFLAGS; I /think/ there is a mechanism
to allow specifying a config file to be used instead of using the one
Configure.pl would build after probing your system. Can any parrot
porters who've done this (all 2 of you) jump in here?

[Joel Sherrill]

On 02/09/2010 07:32 AM, Will Coleda wrote:
> On Mon, Feb 8, 2010 at 7:46 PM, Chris Johns<chr...@rtems.org> wrote:
>
>> On 2/9/2010 9:01 AM, Joel Sherrill wrote:
>>
>>> 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.
>>>
> This can be done by passing a parameter to Configure.pl - see the
> --help on that for adding CFLAGS.
>
>

Chris is the one who has done all the work so far. He is in
Sidney so we will have to wait for him to comment.

>> If Parrot builds tools on the host require to build the target code there
>> needs to be 2 separate sets of flags. Does it ? Typically HOST_CFLAGS
>> handles the host and CFLAGS handles the target. This also goes for CC where
>> HOST_CC handles the host compiler and CC is the target compiler.
>>
>> Chris
>> _______________________________________________
>> http://lists.parrot.org/mailman/listinfo/parrot-dev
>>
>>
> We don't go out of our way to support cross-platform compilation at
> the moment; we don't use HOST_CFLAGS; I /think/ there is a mechanism
> to allow specifying a config file to be used instead of using the one
> Configure.pl would build after probing your system. Can any parrot
> porters who've done this (all 2 of you) jump in here?
>
>

--
Joel Sherrill, Ph.D. Director of Research& Development
joel.s...@OARcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985

_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev

[Jonathan Leto]

Howdy,

>> If Parrot builds tools on the host require to build the target code there
>> needs to be 2 separate sets of flags. Does it ? Typically HOST_CFLAGS
>> handles the host and CFLAGS handles the target. This also goes for CC where
>> HOST_CC handles the host compiler and CC is the target compiler.
>>
>> Chris
>

> We don't go out of our way to support cross-platform compilation at
> the moment; we don't use HOST_CFLAGS; I /think/ there is a mechanism
> to allow specifying a config file to be used instead of using the one
> Configure.pl would build after probing your system. Can any parrot
> porters who've done this (all 2 of you) jump in here?
> --
> Will "Coke" Coleda

Let it be know that yes, we now *are* going out of our way to support
cross-platform compilation. I am working on porting Parrot to two new
platforms:

1) RTEMS - which is actually a whole slew of platforms
2) BUG - PokyLinux on ARM1136JF-S (ARMv6 RISC)

Chris Johns did most of the work getting Parrot to use RTEMS
cross-compile subsystem and I am working on integrating the necessary
changes into the Parrot codebase.

I know that these new platforms are not *officially* supported, but
they are very high on my task list and I hope that with the help of
some GSoC students this year, they will become officially supported in
the near future.

Duke

[Will Coleda]

Whoops. Forgot to read that in a marketing light. Yes. I only meant
that the tools we have don't currently make it amazingly easy for you.

Thanks for clarifying, Duke.

[Chris Johns]

Will Coleda wrote:
> On Mon, Feb 8, 2010 at 7:46 PM, Chris Johns <chr...@rtems.org> wrote:
>> On 2/9/2010 9:01 AM, Joel Sherrill wrote:
>>> 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.
>
> This can be done by passing a parameter to Configure.pl - see the
> --help on that for adding CFLAGS.

I tried:

perl Configure.pl --cc=m68k-rtems4.10-gcc --cxx=m68k-rtems4.10-g++
--link=m68k-rtems4.10-gcc --ld=m68k-rtems4.10-gcc --without-gdbm
--without-gettext --without-crypto --without-gmp --without-opengl
--without-pcre --verbose=2

and the error was:

inter::progs - Determine what C compiler and linker to use...

m68k-rtems4.10-gcc -D_REENTRANT -D_GNU_SOURCE -DDEBUGGING -pipe
-I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
-I/usr/include/gdbm -I./include -c test_4530.c
m68k-rtems4.10-gcc -Wl,-E test_4530.o -o test_4530 -lresolv -lnsl -ldl -lm
-lcrypt -lutil -lpthread -lrt
/opt/rtems-4.10/lib/gcc/m68k-rtems4.10/4.4.3/../../../../m68k-rtems4.10/bin/ld:
cannot find -lresolv

RTEMS has a different header file and library model and this test seems to
assume something else.

>
>> If Parrot builds tools on the host require to build the target code there
>> needs to be 2 separate sets of flags. Does it ? Typically HOST_CFLAGS
>> handles the host and CFLAGS handles the target. This also goes for CC where
>> HOST_CC handles the host compiler and CC is the target compiler.
>>
>> Chris
>> _______________________________________________
>> http://lists.parrot.org/mailman/listinfo/parrot-dev
>>
>
> We don't go out of our way to support cross-platform compilation at
> the moment;

Our hope is this changes with our support.

> we don't use HOST_CFLAGS;

It may or may not be a problem and was only a heads up. I see you use perl to
handle this task and that may avoid the need for a host CC. This is beyond my
understanding of your build system.

> I /think/ there is a mechanism
> to allow specifying a config file to be used instead of using the one
> Configure.pl would build after probing your system.

What do you mean by "probing" ?

> Can any parrot
> porters who've done this (all 2 of you) jump in here?
>

Chris
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev

[Andy Dougherty]

On Tue, 9 Feb 2010, Will Coleda wrote:

> 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. =-)
>
> @cc_warnings:s/-Wno-unused/unused/@
>
> is my current thought - we only need a way to specify a change, since
> that syntax covers addition/removal also.

At a quick glance, that looks ok. It does suffer from the same problem as
the current mechanism: It's sometimes difficult to conditionally apply.
For example, there's no easy way to say something like

For compiling src/gc/system.c on amd64 on certain flavors of Linux
with gcc 4.3.x, optimizations -O[012] are fine, but -O3 and higher
won't work.

That's a limitation of the current system too, but it could be useful to
implement. While you're poking at the CFLAGS anyway, it's something to
bear in mind, in case a natural implementation suggests itself.

[James E Keenan]

Chris Johns wrote:

> Will Coleda wrote:
>
>> I /think/ there is a mechanism
>> to allow specifying a config file to be used instead of using the one
>> Configure.pl would build after probing your system.
>

perldoc Configure.pl
... then search for: Configuration-File Interface
... This was a feature that Jerry Gay (particle) requested about three
years ago specifically so that someone, in the far distant future, would
have a starting point for cross-platform compilation.

> What do you mean by "probing" ?
>

In non-cross-platform compilation -- heretofore 99.9% of all situations
where Parrot has been built -- you call 'perl Configure.pl'
(command-line options to taste) and it goes through 60+ individual steps
that fall into 4 broad categories:

* init: Initialization from defaults we've selected, option values
you've specified on command-line (or in file), Perl 5 %Config, compiler
and/or platform hints.
* inter: Steps where, if you have selected interactive configuration on
the command-line, Configure.pl will offer you a number of choices based
on what it finds on disk, e.g., which 'make' do you want to use?
AFAICT, interactive configuration is little used at the present time,
but it has some passionate and knowledgeable defenders.
* auto: Automated probes -- this is what you were getting at. We
construct little C programs from templates, run them on the fly, and
study their output to determine characteristics of your platform.
* gen: Generate Makefile(s) and other files used by 'make'. During the
previous 3 steps configuration data is stored inside the
Parrot::Configure object. During 'gen' steps, we consult that data and
generate files.

In addition to the aforementioned documentation for Configure.pl, you
should also try:

perldoc docs/configuration.pod

HTH

kid51

_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev

[Will Coleda]

Whoops. We're overengineering some of this.

If we want to change a warnings flag, we just need to tack it on the
end of the command line, the second -Wno-foo will override the default
-Wfoo.

We can use the existing makefile generation step to conditionally add
the -Wno-foo, using the #IF and #UNLESS directives already present.

That just leaves the optimization as something to specify separately.
If we need to get that specific about some of the files optimization
levels, we can add a new config step to specify the particulars
per-file. The existing rules in CFLAGS are probably doable without
jumping through that hoop, though.

[Andy Dougherty]

On Wed, 10 Feb 2010, Will Coleda wrote:

> On Tue, Feb 9, 2010 at 7:15 PM, Andy Dougherty <doug...@lafayette.edu> wrote:

> > For example, there's no easy way to say something like
> >
> >    For compiling src/gc/system.c on amd64 on certain flavors of Linux
> >    with gcc 4.3.x, optimizations -O[012] are fine, but -O3 and higher
> >    won't work.
> >

> Whoops. We're overengineering some of this.

I don't think so. That example is very real and almost precisely the
current state of affairs. There are many other examples in the perl 5
tree.

> If we want to change a warnings flag, we just need to tack it on the
> end of the command line, the second -Wno-foo will override the default
> -Wfoo.

Yes, that works for gcc. I don't know about other compilers, but since we
don't really support warnings on other compilers anyway, that's good
enough for now.

> We can use the existing makefile generation step to conditionally add
> the -Wno-foo, using the #IF and #UNLESS directives already present.

Yes, but they are too blunt a tool for the task above. They are all we
have, so that's what we do now, but they are still inadequate. They don't
fail, but they are suboptimal. That's all I'm saying.

Your plan preserves the status quo, which is ok, but if you can think of a
way to generalize it, I think it would be beneficial. That's all I was
trying to say.

--
Andy Dougherty doug...@lafayette.edu

[Will Coleda]

Once we get to the point where we are autogenerating the dependencies,
I think adding this level of complexity will be much easier. I
envision a makedepend step at some point that lets you get some
flexibility when you run it, but then renders it out so that ongoing
configs and builds don't have to run any of that logic.

I'm definitely interested in properly handling more compiler's warnings.

[Will Coleda]

On Wed, Feb 10, 2010 at 9:47 AM, Andy Dougherty <doug...@lafayette.edu> wrote:

I'm pretty sure that the rm_cflags branch will now break the build for
any non-gcc compiler; can someone give it a shot? All my development
environments are GCC at this point. (Strawberry perl on windows,
generic linux box.)

[Andy Dougherty]

On Fri, 12 Feb 2010, Will Coleda wrote:

> I'm pretty sure that the rm_cflags branch will now break the build for
> any non-gcc compiler; can someone give it a shot? All my development
> environments are GCC at this point. (Strawberry perl on windows,
> generic linux box.)

You are correct. On OpenSolaris with Sun's cc, first try I got

cc: -W option with unknown program no-unused-parameter

As you undoubtedly suspected, non-gcc compilers don't necessarily know
what to do with those options.

Removing those invalid options from the Makefile (and from
compilers/imcc/Rules.mak), I got as far as

ld.so.1: iropt: fatal: relocation error: file
/opt/SunStudioExpress/prod/bin/iropt: symbol _printstack: referenced
symbol not found
cc: Fatal error in /opt/SunStudioExpress/prod/bin/iropt : Killed
*** Error code 9
make: Fatal error: Command failed for target `src/ops/core_ops_switch.o'

which turns out to be due to optimization level I use in my build script.
In the old CCFLAGS, optimization was turned off for the core_ops*.c files.
Now it's not. That file overwhelms the compiler with optimization
turned on, and the compiler hits a resource limit and ungracefully
crashes.

Turning off optimization, it builds. The only tests it fail are
t/run/exit.t, tests 2, 4, 6, and 8. All of them fail with the unhelpful
and unenlightening error message:

t/run/exit....NOK 2# Failed test (t/run/exit.t at line 45)
# '0'
# ne
# '0'

However, I suspect that's unrelated to CCFLAGS, and haven't pursued
it further.

[Will Coleda]

On Wed, Feb 10, 2010 at 9:47 AM, Andy Dougherty <doug...@lafayette.edu> wrote:

What about this for a more clever @@ replacement syntax? then we can
setup something complicated per-file but have a sane default.

--

Takes the specified source file, replacing entries like C<@key@> with
C<key>'s value from the configuration system's data, and writes the results
to specified target file.

If a C<?> is present in the C<@key@>, the replaced value will first
try touse the full key, but if that is not present, the key up to the
C<?> is used.
For example, if C<@cc_warnings?src/embed.c@> is used, and that key doesn't
exist, the fallback key would be C<@cc_warnings@>.

[Andy Dougherty]

On Fri, 12 Feb 2010, Will Coleda wrote:

> What about this for a more clever @@ replacement syntax? then we can
> setup something complicated per-file but have a sane default.
>
> --
>
> Takes the specified source file, replacing entries like C<@key@> with
> C<key>'s value from the configuration system's data, and writes the results
> to specified target file.
>
> If a C<?> is present in the C<@key@>, the replaced value will first
> try touse the full key, but if that is not present, the key up to the
> C<?> is used.
> For example, if C<@cc_warnings?src/embed.c@> is used, and that key doesn't
> exist, the fallback key would be C<@cc_warnings@>.

I think that could work. My initial inclination would have been to use an
existing syntax, perhaps something like C<$cc_warnings{'src/embed.c'}>,
instead of inventing a new syntax, but it doesn't really matter very much.
He who implements it gets to choose. The main thing is it should
ultimately be easy for a porter to add a specific case to a hints file
that will then get used up by the general config mechanism.

I'm afraid that I'm unlikely to have any opportunity to do anything useful
with this for quite a while, so go with whatever makes sense to you.

[chromatic]

On Tuesday 16 February 2010 at 18:50, Andy Dougherty wrote:

> I'm afraid that I'm unlikely to have any opportunity to do anything useful
> with this for quite a while, so go with whatever makes sense to you.

Ultimately we want cleanliness of course, but we also want to make sure that
we can take advantage of your knowledge and the platforms to which you have
access. If things don't get easier for you to work on Parrot, we'll have
failed one of our most important goals.

-- c
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev

[Andy Dougherty]

On Tue, 16 Feb 2010, chromatic wrote:

> On Tuesday 16 February 2010 at 18:50, Andy Dougherty wrote:
>
> > I'm afraid that I'm unlikely to have any opportunity to do anything
> > useful with this for quite a while, so go with whatever makes sense to
> > you.
>
> Ultimately we want cleanliness of course,

For the rm_flags branch, it's currently not an issue of cleanliness. It
simply doesn't build with anything other than gcc[*] (and probably not
with gcc -O3 on amd64/Linux). There were things in the old CFLAGS
mechanism which need to somehow be accomodated in the new order. I believe
Coke is well aware of these and working on them, but hasn't had time to
finish them yet.

More broadly, the old CFLAGS way was indeed incredibly roundabout and
clunky; the new way forward is potentially both simpler and more flexible.

[Will Coleda]

On Wed, Feb 17, 2010 at 9:12 AM, Andy Dougherty <doug...@lafayette.edu> wrote:
> On Tue, 16 Feb 2010, chromatic wrote:
>
>> On Tuesday 16 February 2010 at 18:50, Andy Dougherty wrote:
>>
>> > I'm afraid that I'm unlikely to have any opportunity to do anything
>> > useful with this for quite a while, so go with whatever makes sense to
>> > you.
>>
>> Ultimately we want cleanliness of course,
>
> For the rm_flags branch, it's currently not an issue of cleanliness.  It
> simply doesn't build with anything other than gcc[*] (and probably not
> with gcc -O3 on amd64/Linux).  There were things in the old CFLAGS
> mechanism which need to somehow be accomodated in the new order. I believe
> Coke is well aware of these and working on them, but hasn't had time to
> finish them yet.

And... done.

> More broadly, the old CFLAGS way was indeed incredibly roundabout and
> clunky; the new way forward is potentially both simpler and more flexible.
>
> --
>    Andy Dougherty              doug...@lafayette.edu
> _______________________________________________
> http://lists.parrot.org/mailman/listinfo/parrot-dev
>

This branch:
- is warnings clean on GCC. (but probably nothing else)
- removes tools/build/cc_flags.pl - all compilation is now done via
straight makefile rules (and now the actual compiler command is
visible, where it was hidden in trunk.)
- eliminates a bunch of unused static functions, variables and other
warnings (instead of skipping them as we used to.)
- creates a @foo::bar@ syntax for makefile substitution - if foo::bar
is present, it's used, otherwise we fall back to foo.
- eliminates "replace_slashes" in the makefile. (and uses @slash@ in
the few cases where it is necessary, i.e. command paths.)
- kills the legacy INVERSE_CONDITIONED_LINE syntax.
- makes compilers/imcc/Rules.mak a generated file so we can use the
makefile.in syntax.
- eliminates most of config's auto:cgoto - these are now just part of
the makefile.
- updates config's init::optimize to put the optimize flags in
@optimize@, with file-specific overrides, and update all invocations
of CC to use this config var.
- update config's auto::warnings to keep track of per-file warnings
overrides in a hopefully easy to use data structure that should allow
for additions other than the current gcc/g++ variants; don't expose as
much of our decision making process here in config vars as we used to.
break out warnings into @ccwarn@ instead of adding them to CFLAGS.
generate file specific overrides (and use them in the makefiles).
- move g++ vs. gcc check out of auto::warnings into auto::gcc
- fix test file used to see if warnings are valid to be warnings clean
- some valid warnings were not being picked up because of this.

Needs testing on sun's CC and amd64, and windows.

[François Perrad]

2010/3/4 Will Coleda <wi...@coleda.com>:

FAIL with mingw (gcc 3.4.5)

gcc -I./include -I./include/pmc -DWIN32 -DHASATTRIBUTE_CONST
-DHASATTRIBUTE_DEPRECATED -DHASATTRIBUTE_MALLOC
-DHASATTRIBUTE_NONNULL -DHASATTRIBUTE_NORETURN -DHASATTRIBUTE_PURE
-DHASATTRIBUTE_UNUSED -DHASATTRIBUTE_WARN_UNUSED_RESULT
-DDISABLE_GC_DEBUG=1 -DNDEBUG -DHAS_GETTEXT -I
C:\icu-4.2.1\icu\include -DHAVE_COMPUTED_GOTO -s -O2
-falign-functions=16 -fvisibility=hidden -Isrc/string -o
src/string/api.o -c src/string/api.c
cc1.exe: error: unrecognized command line option "-fvisibility=hidden"
make: *** [src/string/api.o] Error 1

C:\fperrad\Parrot\rm_cflags>gcc -v
Reading specs from C:/MinGW/bin/../lib/gcc/mingw32/3.4.5/specs
Configured with: ../gcc-3.4.5-20060117-3/configure --with-gcc
--with-gnu-ld --with-gnu-as --host=mingw32 --target=mingw32
--prefix=/mingw --enable-threads --disable-nls
--enable-languages=c,c++,f77,ada,objc,java --disable-win32-registry
--disable-shared --enable-sjlj-exceptions --enable-libgcj
--disable-java-awt --without-x --enable-java-gc=boehm
--disable-libgcj-debug --enable-interpreter
--enable-hash-synchronization --enable-libstdcxx-debug
Thread model: win32
gcc version 3.4.5 (mingw-vista special r3)

François

> --
> Will "Coke" Coleda
> _______________________________________________
> http://lists.parrot.org/mailman/listinfo/parrot-dev
>
>

_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev

[chromatic]

On Wednesday 03 March 2010 at 23:58, François Perrad wrote:

> FAIL with mingw (gcc 3.4.5)
>
> gcc -I./include -I./include/pmc -DWIN32 -DHASATTRIBUTE_CONST
> -DHASATTRIBUTE_DEPRECATED -DHASATTRIBUTE_MALLOC
> -DHASATTRIBUTE_NONNULL -DHASATTRIBUTE_NORETURN -DHASATTRIBUTE_PURE
> -DHASATTRIBUTE_UNUSED -DHASATTRIBUTE_WARN_UNUSED_RESULT
> -DDISABLE_GC_DEBUG=1 -DNDEBUG -DHAS_GETTEXT -I
> C:\icu-4.2.1\icu\include -DHAVE_COMPUTED_GOTO -s -O2
> -falign-functions=16 -fvisibility=hidden -Isrc/string -o
> src/string/api.o -c src/string/api.c
> cc1.exe: error: unrecognized command line option "-fvisibility=hidden"
> make: *** [src/string/api.o] Error 1

To the best of my knowledge, that's a GCC 4.x flag. What's the most recent GCC
version supported by mingw?

[Will Coleda]

That parameter is probed for in config/auto/warnings.pm - that module
didn't recognize your compiler's complaint that it wasn't a supported
option, so it included it. I just made that check marginally smarter,
so the probe should now realize it's not a supported option and let
you get further.

Thanks for the report.

[Andy Dougherty]

On Wed, 3 Mar 2010, Will Coleda wrote:

> This branch:
[many nice enhancements elided . . . ]

> Needs testing on sun's CC and amd64, and windows.

Works just fine on OpenSolaris with sun's cc. (I did get "90 subtests
UNEXPECTEDLY SUCCEEDED", but they were in t/dynoplibs/random-range, and I
expect they have nothing to do with this branch.)

Nice job. It sounds like a cleaner, simpler, and yet more powerful plan.

Thank you.

[Will Coleda]

There was a pretty big bug in the probing logic. Fixed now. (Worked
for andy because he's on the "not-gcc" path, but since you are using a
gcc variant, you caught it. Thanks. =-)

Can you confirm it's ok for you now?

[Will Coleda]

Tene++ merged this back to trunk earlier today; particle++ has id'd or
fixed the few windows issues, ttbot shows we're green.

Thanks to everyone who tested.