From: Vladimir Prus (ghost_at_[hidden])
Date: 2005-02-11 06:07:39
On Thursday 10 February 2005 20:07, TEMPLIE Cédric wrote:
> I have sources that are on a network share (S:) I also copy results of
> the build (not intermediate object, I mean .obj...) in S:
> After a build, I relaunch exactly the same command, and it start the
> rebuild... The thing seems to not append when the sources and results
> are on the local computer.
"seems" seems problematic. The first thing I'd suggest is to verify 100% that
this problem only happens with shared directory.
> I provide you logs (d+12) of the second build (normally I supposed
> nothing to rebuild). Could you explain me what are the files that need
> rebuild according to this log, and also what is the condition why there
> is a rebuild... (last time you succeed to tell me because the timestamp
> of header files was wrong...).
It's pretty easy to read the logs. The "->" marks show "interesting" targets.
Then "Outdated" line says that target is rebuilt because dependencies are
newer. So we find thisL
-> 3 Name: <pC :
: Outdated, updating it
: Depends on <pS
: Depends on <pS
The "max time" means the timestamp of the dependency is most recent among all
So: rsp file is on disk C and depends on su_base.dll, which is on disk S:. The
su_base.dll modification time is larger than modification time of rsp file.
One possible reason is that either Sambda or the server where Samba is running
rounds up the modification time to multiple of 2 seconds -- some Windows
version tend to do this. And if the time is rounded *up*, you get what you
get. Shared file timestamp becomes larger. But this is just a guess.
Try using the "build-dir" project attribute so that everything is built to the
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk