Hi Daniel,
> > 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
headers.
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:
http://sourceforge.net/mailarchi
ve/forum.php?thread_id=9710540&forum_id=9097
http://sourceforge.net/mailarchi
ve/forum.php?thread_id=9710539&forum_id=9097
it differs only by the location where new code is added, and
extra comments
and tests.
Can you undo the patch I've sent previously, update to
current CVS and see if
everything's OK.
- Volodya
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
|