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/