[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: not rebuilding out-of-date derived^2 objects

From: Alan Grow
Subject: Re: not rebuilding out-of-date derived^2 objects
Date: Wed, 21 Apr 2004 08:23:24 +0000


Thanks for the advice. I did at last figure out that foo.o's sigtype was the problem. See patch at end. Probably there is a better solution but this is a quick fix, just defaults the sigtype of all targets with builders, but no builder->{env}, to 'build'. Your sigtype function in Construct might work too.

Sorry for confusing everyone with my test I said, in reality I am building nothing of the sort & certainly am an adherent to the 1 Conscript <=> 1 final binary policy. This was just an example. I am also pretty much stuck with Command since I'm building all kinds of weird things with all kinds of weird tools.


--- cons-new    2004-04-21 02:42:38.718046400 -0500
+++ cons        2001-05-25 12:07:31.000000000 -0500
@@ -3258,12 +3258,6 @@
        @sigarray = @{$builder->{env}->{SIGNATURE}};
        $default = [qw(build)];
-               else
-               {
-                       @sigarray = qw(build);
-                       $default = [qw(build)];
-               }
    my $path = $self->path;
    while (@sigarray) {
        my($glob, $aref) = splice(@sigarray, 0, 2);

From:  rick.croote
Subject:  Re: not rebuilding out-of-date derived^2 objects
Date:  Mon, 19 Apr 2004 17:45:42 -0500



You are fighting it. First, from a high level, you will be ahead of the game if you treat each Conscript as if it were a "Project" file. Best to use one project, ie lib or executable, per Conscript. Not the law, but just easier to maintain. Further, it does not make sense to have source in a different Conscript from the "Project file", so is your lib is built in the same conscript as the source that goes into it you will be way ahead.

We have been using Cons very successfully. Our current Cons build, builds some 8000 source files with over 500 projects. And it does so very quickly and reliably. We use ONE Construct file, of which I use to read one Construct.XML file that together manages all system wide tools and their options. All options in the individual Conscripts are treated as overrides and should be justified.

In a previous email, I recommended the use of Conscript_chdir, and I still advocate that your life will be easier if you add it to your Construct, to that end, my further examples will assume you have done so.

Add prior to creating an instance of cons:
Conscript_chdir 1;

Now for the hard part, you delete you lib\Conscript file and change your src\Conscript to read as:

#!/usr/bin/perl -w

Import qw(env);

my @infiles = qw(

$env->Library('#lib/libfoo', @infiles);

You should now note that changing your foo.h file rebuilds all necessary components.

Now, as for what was wrong with your setup. Technically, nothing, it is a bug in Cons I reported long ago that prevents the signatures from properly propagating when using the Command function. Add the following to the bottom of your Construct file and it should fix it.

package file;

sub sigtype {
   my $self = shift;

# If there is already a sigtype, this function is going to do nothing other
   # than exit with the sigtype already assigned.  This is the same as the
   # original method.
   unless ($self->{sigtype})
       # New functionality.
       # If there is already a signature, set the $sigtype to the type of
       # signature found.
       foreach (qw(bsig csig))
           if ($self->{$_})
               $self->{sigtype} = $_;

   unless ($self->{sigtype})
# Set the $sigtype to a build signature, if that type is found in the
       # sigarray.  DON'T ask me why!!!
       $self->{sigtype} = 'bsig' if grep {$_ eq "build"} $self->sigarray;

   # New functionality.
   # Default to a content signature.
   $self->{sigtype} ||= 'csig';

"Alan Grow" <address@hidden>
Sent by:

04/17/2004 05:43 PM

       To:        address@hidden
       cc:        (bcc: Rick Croote/ATL-BTL/MS/PHILIPS)
       Subject:        not rebuilding out-of-date derived^2 objects


Cons 2.3.0 isn't rebuilding "derived derived objects" correctly for me.
I've attached a tarball you can use to reproduce the behavior, but here's
what's going on...

I am building libfoo.a from foo.o, which is built from foo.h and foo.cpp
in turn. The first time I cons, everything is rebuilt. Then if I add a new
function (say) to foo.h and cons again. This time foo.o is rebuilt but
libfoo.a is not, even though foo.o's contents have changed.

I have left SourceSignature and SIGNATURE alone so they should be
defaulting to 'build', but it doesn't seem to matter. Also I am using two
Conscript files, one for the object file and one for the lib, because this
mimics the situation I first encountered the problem in. Anyway untar and
have a look for yourself.

Am I using cons in a way that wasn't intended? Any ideas?


Cons URL:

Description: Binary data

Stop worrying about overloading your inbox - get MSN Hotmail Extra Storage!

reply via email to

[Prev in Thread] Current Thread [Next in Thread]