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

"Alan Grow" <[email protected]> Mon, 19 Apr 2004 05:57:22 +0000
Newsgroups gmane.comp.gnu.cons.general
Message-ID <[email protected]>
>From: Malcolm Blaney <[email protected]>
>To: Alan Grow <[email protected]>
>CC: [email protected]
>Subject: Re: not rebuilding out-of-date derived^2 objects
>Date: Mon, 19 Apr 2004 11:19:39 +0930
>
>Alan Grow wrote:
>>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.
>
>Please don't attatch a tar, just include the Construct & Conscript in your 
>email, it's not that much code...

Okay I just wanted you to be able to quickly reproduce my problem. 
Personally I would have been irritated, and wouldn't bother responding, if 
someone hadn't provided this convenience for me.

>
>>  Am I using cons in a way that wasn't intended?
>
>Yes, the Program and Library methods are designed to do what you're trying 
>to do with Command. You're missing the dependency between foo.o and 
>libfoo.a, which you should see when running cons -d.

I am well aware of the Program and Library methods. This is just an example 
that reproduces the problem, in reality I am building something totally 
different--an nsis installer that includes csharp assemblies and a lot of 
other garbage.

After modifying foo.h:

cons -d

Target lib/libfoo.a: src/foo.o src/foo.o
Checking lib/libfoo.a
  Checking src/foo.o
    Checking src/foo.cpp
    Checking src/foo.h
    Checking /usr/bin/g++
  Rebuilding src/foo.o: out of date.
/usr/bin/g++ -Isrc -o src/foo.o -c src/foo.cpp
  Checking /usr/bin/ar
Target src/foo.o: src/foo.cpp src/foo.h

This shows that libfoo.a is indeed dependent on foo.o. You can add an 
explicit $env->Depends to lib/Conscript if you don't believe me.

>
>Have a look at the examples in the docco, and use/put the compiler commands 
>in the env object in the Construct file.
>
>Malcolm.
>

Why would I put all my compiler commands in Construct? My build is large and 
hierarchical, and has many points of entry.

I still think something is amiss here.

-Alan

_________________________________________________________________
Lose those love handles! MSN Fitness shows you two moves to slim your waist. 
http://fitness.msn.com/articles/feeds/article.aspx?dept=exercise&article=et_pv_030104_lovehandles



_______________________________________________
[email protected]
http://mail.gnu.org/mailman/listinfo/cons-discuss
Cons URL: http://www.dsmit.com/cons/