Small perl task for the interested
Dan Sugalski
warping to dive into...
We could really use the capability of specifying per-C-file flags in
the make procedure, something that can be built into Configure. Right
now we build without optimizations on, which is fine, but I'd like to
turn them on in the future.
They can't be turned on unconditionally, since tsq.c *can't* have any
optimizations turned on for it. (That's the thread-safe queue module,
something that is annoyingly execution-order-dependent because it has
to operate safely as interrupt code potentially interrupting itself
as non-interrupt code) And, if Perl 5 is any guide (and I think it
is) there will be some platform/compiler combinations that won't be
able to compile one or more source modules with the highest
optimization level, but will be able to manage with a lower one.
So... Configure.pl needs to be able to build a makefile that has
per-C-file flags, and those flags need to be overridable per-file at
configure time by the platform configuration module.
Any takers? :)
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
David Robins
> per-C-file flags, and those flags need to be overridable per-file at
> configure time by the platform configuration module.
Does the makefile need to be a typical 'make' makefile or is an all-perl
solution viable?
--
Dave
Isa. 40:31
Dan Sugalski
After three or four false starts... I don't really care. Right now
we're generating makefiles because they're relatively easy, and at
some point we're going to want a two stage build (one platform-native
script, the other some combination of the languages parrot can
compile to bytecode from) but in the interim, well, if you're
interested in redoing it all from makefiles, go for it.
The only thing I ask, and I won't check in without it, is that either
the resulting build script or the config system that generates the
script be adequately understandable, so we can maintain the thing.
Lars Balker Rasmussen
> We could really use the capability of specifying per-C-file flags in
> the make procedure, something that can be built into Configure. Right
> now we build without optimizations on, which is fine, but I'd like to
> turn them on in the future.
>
> They can't be turned on unconditionally, since tsq.c *can't* have any
> optimizations turned on for it. (That's the thread-safe queue module,
> something that is annoyingly execution-order-dependent because it has
> to operate safely as interrupt code potentially interrupting itself as
> non-interrupt code) And, if Perl 5 is any guide (and I think it is)
> there will be some platform/compiler combinations that won't be able
> to compile one or more source modules with the highest optimization
> level, but will be able to manage with a lower one.
>
> So... Configure.pl needs to be able to build a makefile that has
> per-C-file flags, and those flags need to be overridable per-file at
> configure time by the platform configuration module.
I've taken this very simple approach to the problem. A perl-wrapper
for the CC lines in makefiles/root.in
.c$(O) :
$(PERL) tools/dev/cc_flags.pl $(CC) $(CFLAGS) ${cc_o_out}$@ -c $<
that takes a rules-based approach to removing or adding options to the
command-line, based on the filename of the .c-file. This gives some
overhead while building, but it keeps the complexity of the solution
down a lot.
Right now, the configure system has nothing to do with it, but it'd be
fairly simple to make it write a file like following example:
----------------------------------------------------------------------
# File: CFLAGS
# [ filename | {regex} ] -{removed option} +{added option} ...
spf_render.c -{-Wformat-nonliteral}
{^core} +{-O3}
----------------------------------------------------------------------
What're peoples opinion?
Script:
----------------------------------------------------------------------
#!/usr/bin/perl -w
use strict;
if (open F, "CFLAGS") {
my @options;
while (<F>) {
chomp;
s/#.*//;
next unless /\S/;
my $regex;
if (s/^\{(.+?)\}\s*//) {
$regex = qr/$1/;
}
elsif (s/^(\S+)\s*//) {
$regex = qr/^\Q$1\E$/;
}
else {
die "syntax error in CFLAGS: line $., $_\n";
}
while (s/^([-+])\{(.+?)\}\s*//) {
push @options, [ $regex, $1, $2 ];
}
if (/\S/) {
die "syntax error in CFLAGS: line $., $_\n";
}
}
my ($cfile) = grep /\.c$/, @ARGV;
foreach my $option (@options) {
if ($cfile =~ $option->[0]) {
if ($option->[1] eq '+') {
splice @ARGV, 1, 0, $option->[2];
}
else {
@ARGV = grep { $_ ne $option->[2] } @ARGV;
}
}
}
}
print "@ARGV\n";
exec @ARGV;
__END__
Cheers,
--
Lars Balker Rasmussen Consult::Perl
Lars Balker Rasmussen
The lines should probably just be removed (as well as lex/bison in
@args and elsewhere), since $yacc/$lex are specifically handled above,
but I wasn't sure what the intended purpose was.
Anyway, giving --lex or --yacc arguments to Configure.pl will break
the build-process with these.
$cc_warn=$args{lex} if defined $args{lex};
$cc_warn=$args{yacc} if defined $args{yacc};
Josh Wilmes
At 12:48 on 07/14/2003 +0200, Lars Balker Rasmussen <la...@balker.org> wrote:
> I've taken this very simple approach to the problem. A perl-wrapper
> for the CC lines in makefiles/root.in
>
> .c$(O) :
> $(PERL) tools/dev/cc_flags.pl $(CC) $(CFLAGS) ${cc_o_out}$@ -c $<
I would go a bit further, and create a tools/build/compile, tools/build/
link_executable, tools/build/link_library, etc.
Take all the flags out of the makefile altogether. Just a thought.
--Josh
Benjamin Goldberg
Josh Wilmes wrote:
>
> At 12:48 on 07/14/2003 +0200, Lars Balker Rasmussen <la...@balker.org> wrote:
>
> > I've taken this very simple approach to the problem. A perl-wrapper
> > for the CC lines in makefiles/root.in
> >
> > .c$(O) :
> > $(PERL) tools/dev/cc_flags.pl $(CC) $(CFLAGS) ${cc_o_out}$@ -c $<
>
> I would go a bit further, and create a tools/build/compile, tools/build/
> link_executable, tools/build/link_library, etc.
That would be silly. Instead, specify the file to read the flags from
as the first argument to cc_flags.pl. That is, change:
if (open F, "CFLAGS") {
To:
if (open F, shift @ARGV) {
Then:
c$(O) :
$(PERL) tools/dev/flags.pl CFLAGS $(CC) $(CFLAGS) \
${cc_o_out}$@ -c $<
And for linking, flags.pl gets an argument of LINKFLAGS, and for making
a shared library, it gets an argument of SHAREFLAGS, etc.. In each of
those files are rules for the per-file flags for that type of step.
> Take all the flags out of the makefile altogether. Just a thought.
>
> --Josh
--
$a=24;split//,240513;s/\B/ => /for@@=qw(ac ab bc ba cb ca
);{push(@b,$a),($a-=6)^=1 for 2..$a/6x--$|;print "$@[$a%6
]\n";((6<=($a-=6))?$a+=$_[$a%6]-$a%6:($a=pop @b))&&redo;}
Josh Wilmes
I think you miss the point. It's not just about flags. It's about how
you do a particular task, which could involve one or more commands (or be
impossible).
See libtool for an idea of the size of the problem.
--Josh
Lars Balker Rasmussen
>> .c$(O) :
>> $(PERL) tools/dev/cc_flags.pl $(CC) $(CFLAGS) ${cc_o_out}$@ -c $<
>
> I would go a bit further, and create a tools/build/compile, tools/build/
> link_executable, tools/build/link_library, etc.
>
> Take all the flags out of the makefile altogether. Just a thought.
It's a good idea, though the correct approach would be to return to
only using a modified version of make.pl - but it's a lot more work
than merely extending the current system. For now, I've focused only
on the requirements Dan had.
The suggestion by Benjamin Goldberg was already in the patch already
committed. Modifying the link-step the way Benjamin suggests is
trivial, although I suggest we wait until the need arises.
Gordon Henriksen
> At 12:48 on 07/14/2003 +0200, Lars Balker Rasmussen <la...@balker.org>
> wrote:
>
>> I've taken this very simple approach to the problem. A
>> perl-wrapperfor the CC lines in makefiles/root.in
>>
>> .c$(O) :
>> $(PERL) tools/dev/cc_flags.pl $(CC) $(CFLAGS) ${cc_o_out}$@ -c $<
>
> I would go a bit further, and create a tools/build/compile,
> tools/build/link_executable, tools/build/link_library, etc.
>
> Take all the flags out of the makefile altogether. Just a thought.
qmail's build process does this. It's heart-breakingly beautiful;
Makefiles suddenly start to work like they should.
—
Gordon Henriksen
mali...@mac.com