Re: [boost] [Serialization] Major regressions on RC_1_33_0

From: John Maddock (john_at_[hidden])
Date: 2005-10-10 07:33:04

>>> a) the VC 7.1 errors are most likely due the fact that bjam cannot
>>> be counted upon to detect dependent changes. I had the same problem
>>> on my own VC 7.1 system and had to explicitly rebuild the library
>>> to get the error to go away.
>
> Grr, Robert please stop saying that. It is reliable, as long as the
> dependencies are regular '#include <>' and '#include ""'. So if you
> think it's not handling those cases please point out where so we can
> fix it. If you think it should handle other cases please also point
> those out so we can add support for them.

There is definitely a problem, a clean rebuild does result in a bunch a 
failures, all but one of these goes away if you then build again.  These are 
clearly related to Rene's explanation 
(http://article.gmane.org/gmane.comp.lib.boost.devel/111585) which hasn't 
been applied inspite of a comment in the Jamfile that seems to describe that 
very fix.

I had a grep through the headers and couldn't find any instances of
obfuscated header includes that might trigger a problem in the library,
however in the test sources there are a lot that contain:

#include BOOST_PP_STRINGIZE(BOOST_ARCHIVE_TEST)

BOOST_ARCHIVE_TEST gets defined as a macro in the Jamfile so that different
archive forms (text, binary xml etc) all get tested.

So.... if there is a change in the library the *test* may not get rebuilt.
Robert is that a fair characterisation of the problem?

I don't see any easy solution to this, unless a DEPENDS clause can be added
at the same time as the "run" clause gets added to the tests (inside another
rule that is).  Rene would that be possible?  Any chance you could look at
the Jamfile and figure out how at least one of the DEPENDS clauses should
look so the rest of us mortals could take it from there?

Thanks,

John.