Boost logo

Boost-Build :

From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-11-16 12:03:16


On Tuesday 16 November 2004 19:40, David Abrahams wrote:

> > And, the relevant jamfiles:
> > What first tipped me off to this behavior was running `vi' in the
> > exception directory always triggered a complete rebuild. This is
> > becuase `vi' deposited a .swp file in the exception directory, which
> > causes the directory's timestamp to be newer than the source,
> > triggereing a rebuild. That's why the project is in the directory
> > `vi-boost-interaction' because I was trying to figure out why vi would
> > cause things to rebuild.
> >
> > Thanks for your help!!!
> > -Andy
>
> Sorry, I just wasn't thinking. The collision here is between the
> header <exception> and the first path component of
> <exception/Exception.h>. Okay, that is fortunately easy to fix. All
> we need to do is fix the rules that make directory targets so that
> those targets are gristed slightly differently.

I think the problem is different -- I can reproduce the problem even without
<exception/Exception.h>. Please see the attached setup.

I get this:

bjam
<build the project>
touch exception/a
bjam
<the project is built again>

> Hmm...
>
> Please try this, with v1. Just add
>
> -sdirectory-grist=FuBar
>
> to your bjam command-line. Do you still see these problems?

This did not help in my case. Relevant log lines:

> 3 Name: <a/gcc/debug>a.o
Loc: a/gcc/debug/a.o
: Outdated, updating it
: Depends on <directory-grist>a/gcc/debug (stable)
: Depends on a.cpp (stable)
: Depends on a.cpp (internal node) (stable) (max time)
4 Name: a.cpp
: Stable
4 Name: a.cpp (internal node)
: Stable
: NOTFILE
: Depends on <exception> (stable)
: Depends on exception (newer) (max time)
5 Name: <exception>
Loc:
: Stable
: NOCARE
5 Name: exception
: Newer
: NOCARE

The a.cpp (internal node) is the result of header scanning. Somehow it depends
on two "exceptions" and one if them is "newer".

The HdrRule does:

set SEARCH on <exception> exception =

(that's line from d+5 log) and bjam as fallback always searches in ".".
I'm not sure what to do, except for special "find only file" flag on targets.

- Volodya

 --Boundary-00=_ULjmBNIy5Re6GKe Content-Type: application/x-zip;
name="scanning_conflict_v1.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="scanning_conflict_v1.zip"

[Attachment content not displayed.] --Boundary-00=_ULjmBNIy5Re6GKe--


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