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

[Alan Grow]

Rick,

 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 project...as 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.

 -Alan

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

--------------------------------------------------------------------------------

Alan,

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(
       foo.cpp
       );

$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} = $_;
               last;
           }
       }
   }

   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:
address@hidden

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
       Classification:






Hi,

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?

-Alan

_______________________________________________
address@hidden
http://mail.gnu.org/mailman/listinfo/cons-discuss
Cons URL: http://www.dsmit.com/cons/


derivedtest.tar.gz
Description: Binary data

_________________________________________________________________
Stop worrying about overloading your inbox - get MSN Hotmail Extra Storage! 
http://join.msn.com/?pgmarket=en-us&page=hotmail/es2&ST=1/go/onm00200362ave/direct/01/