Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Small perl task for the interested

17 views
Skip to first unread message

Dan Sugalski

unread,
Jun 26, 2003, 10:09:49 AM6/26/03
to perl6-i...@perl.org
Since folks are at times looking for something small and not mind
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

unread,
Jun 26, 2003, 12:57:57 PM6/26/03
to Dan Sugalski, perl6-i...@perl.org
> 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.

Does the makefile need to be a typical 'make' makefile or is an all-perl
solution viable?

--
Dave
Isa. 40:31

Dan Sugalski

unread,
Jun 29, 2003, 12:44:59 PM6/29/03
to David Robins, perl6-i...@perl.org

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

unread,
Jul 14, 2003, 6:48:03 AM7/14/03
to perl6-i...@perl.org
d...@sidhe.org (Dan Sugalski) writes:
> 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

unread,
Jul 16, 2003, 3:27:52 PM7/16/03
to perl6-i...@perl.org
Found this pecularity in config/inter/progs.pl.

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

unread,
Jul 18, 2003, 9:49:59 PM7/18/03
to Lars Balker Rasmussen, perl6-i...@perl.org

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

unread,
Jul 19, 2003, 6:45:43 PM7/19/03
to perl6-i...@perl.org

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

unread,
Jul 19, 2003, 9:38:26 PM7/19/03
to Benjamin Goldberg, perl6-i...@perl.org

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

unread,
Jul 21, 2003, 5:21:00 PM7/21/03
to Josh Wilmes, Lars Balker Rasmussen, perl6-i...@perl.org
Josh Wilmes <jo...@hitchhiker.org> wrote:
>> .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

unread,
Jul 25, 2003, 8:29:43 AM7/25/03
to perl6-i...@perl.org
On Friday, July 18, 2003, at 09:49 , 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-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

0 new messages