From: Vladimir Prus (ghost_at_[hidden])
Date: 2006-02-13 06:07:27
> > 1. The '<implicit-dependency>' won't automatically build 'msg'. It just
> > means
> > 'I think there's header in 'msg' that this target depends on'. This is by
> > design (though if you think that's wrong design, I'm open to arguments).
> I would expect msg to be built by a bjam test if the mc file changed since
> the header is a dependant of that file. Would you agree?
No, not quite. The header should be rebuilt, because it's dependendant of
".mc" file and it's included by 'log.cpp' and 'log.cpp' is being built.
But you did not request build of the 'msg' target, so it's not build. If you
want 'msg' to be always built when you build 'test', you add the
<dependency>msg. Otherwise, only required target, in this case the generated
header, will be built.
> If msg were a static lib instead of a shared lib, building an exe that
> depended on msg should cause msg to be rebuilt if msg.cpp.
Seems like you've omitted something in that sentence. I assume "if msg.cpp is
out-of-date". Yes, if "exe" target depends on "msg", then "msg" will be
rebuild if msg.mc is modified.
> In this case
> however, I would agree that <implicit-dependency> alone shouldn't cause
> that behavior. In that case, I think the exe target should have both
> <implicit-dependency> and <dependency> to indicate the two subtly different
> dependencies on the msg target.
If your exe uses the library at link time, then add the library to the
sources, and use extra <implicit-dependency> as a hint about generated
If you exe uses a shared library as plugin, it might be desirable to build the
library whenever the exe is built, without linking to it. In that case
<dependency> + <implicit-dependency> is best.
You decide ;-)
If the above explanations are not clear enough, please ask.
> > 2. The *header* should be automatically generated, because it's used from
> > 'log.cpp'. It's not generated, and that's a bug. Pretty subtle one,
> > because
> > if you say "bjam", the dependency between generated header and the
> > including .cpp file will be correctly found, so this bug does not
> > reproduce
> > on whole-project builds.
> > I attach a patch to fix that issue. It will soon be committed, but I'd
> > need to
> > write tests first so this might take more time.
> I applied your patch to my tree and it does cause my real world build to
> work as I would expect even when removing the extraneous <dependency>msg.
Ok, great. I've just comitted the *right* fix for this problem:
it differs only by the location where new code is added, and extra comments
Can you undo the patch I've sent previously, update to current CVS and see if
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