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

[Malcolm Blaney]

Alan Grow wrote:
> 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.

I would say it's the opposite. People don't go to much more effort than 
looking at the email in front of them. :)

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

That's good, shows your code is sort of working! What is _really_ 
strange is that I tried this with 'cons -pa' to see what's going on, and 
then the next time I ran cons properly (ie to do a build) it built the 
library. No changes required. So I would agree that the dependencies 
aren't getting checked properly in cons, but I also wouldn't use the 
'Command' command like this. I've had problems with Command, and so only 
use it if I have to. The fact that it is checking src/foo.o again on the 
last line when it's just built it shows that something is wrong.


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

Importing env should be enough in Conscripts, though if you do need to 
use Command you're right in needing to pull out required fields. But 
that is what Cons is trying to do for you.

Malcolm.