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

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

--
Dave
Isa. 40:31

At 12:57 PM -0400 6/26/03, David Robins wrote:

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

--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai
d...@sidhe.org                         have teddy bears and even
                                       teddy bears get drunk

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

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};

Cheers,
--
Lars Balker Rasmussen                                      Consult::Perl

At 12:48 on 07/14/2003 +0200, Lars Balker Rasmussen <l...@balker.org> wrote:

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

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.

--
$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;}

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  

At 18:45 on 07/19/2003 EDT, Benjamin Goldberg <ben.goldb...@hotpop.com> wrote:

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.

Cheers,
--
Lars Balker Rasmussen                                      Consult::Perl

qmail's build process does this. It's heart-breakingly beautiful;
Makefiles suddenly start to work like they should.

—

Gordon Henriksen
malic...@mac.com