[Gtkradiant] parallell cons, attempt #2

[Timothee Besset]

I already posted here in February about this:
http://mail.gnu.org/pipermail/cons-discuss/2002-February/001736.html

I'm back at it now, with more information and a real will to see this
fixed. See http://zerowing.idsoftware.com/pcons/ for a summary.

I wrote a test case, and a verbosive version of pcons 2.3.1:
http://zerowing.idsoftware.com/pcons/testcase.tar.gz
http://zerowing.idsoftware.com/pcons/pcons-2.3.1-verbose

Here's what happens:

timo@antares:~/Id/cons/pcons/test$ ../pcons-2.3.1-verbose -j4
pcons max jobs set to: 4
./gcc-slow.sh -c func.c -o func.o
wait_on_all_children
Waiting to build (1): func.o
waited: func.o on: 3369parent
./gcc-slow.sh -c main.c -o main.o
wait_on_all_children
Waiting to build (1): main.o
waited: main.o on: parent3375
./gcc-slow.sh -o test main.o func.o
wait_on_all_children
Waiting to build (1): test
waited: test on: parent3381

Basically the wait_on_all_children in _pbuild (line 3962) is called
systematically, and blocks any parallelizing possibility. It looks like
this code block is problematic:

    my $sig;
    {

        # print "in ", $self->path, "\n";
        local ($file::child_queue) = {parent => $self};
        for my $dep (@$rdeps)
        {
            if ((pbuild $dep) eq 'errors')
            {

                # Propagate dependent errors to target.
                # but try to build all dependents regardless of errors.
                $self->{status} = 'errors';
            }
        }
        wait_on_all_children();

    }

My limited perl knowledge doesn't really allow me to investigate further
though.

There .. I hope I'll get answers this time .. I'm even willing to fund
(reasonably) cons maintenance if we can have a reliable 2.3.1 final
release at some point.

TTimo