From: Anthony Williams (anthony_w.geo_at_[hidden])
Date: 2007-11-21 04:19:51
Rene Rivera <grafikrobot_at_[hidden]> writes:
> Anthony Williams wrote:
>> I've changed the headers of boost.thread several times recently, and it has
>> become apparent that those testers doing incremental runs are not picking up the
>> changes, and are thus not rebuilding the tests. This is especially problematic
>> when the library files change too --- the libraries are rebuilt, but the tests
>> are not, which leads to linker errors or crashes depending on the nature of the
>> Is there a way to make boost build aware of the headers belonging to a specific
>> library, so changes to those headers will force recompilation of anything
>> dependent on that library?
> If you can point out which specific headers, and which specific files
> should have been compiled that would be helpful. The automatic
> dependency track of BB should work in most situations. But I can't say
> it's broken without knowing the context.
As an example, I recently changed boost/thread/win32/tss.hpp and the
corresponding functions in libs/thread/src/win32/thread.cpp
Monday's speedsnail-gcc-3.4.5 test_tss failures are showing a link failure
since the signature of boost::detail::set_tss_data has changed.
Likewise with Tuesday night's RudbekAssociates-V2 test_tss failure.
I'm fairly sure that other thread failures recently have been due to
incremental tests not picking up the changes. In some cases the failures are
at runtime (e.g. unexplained crashes), since the size or layout of a type has
changed, but not the function signatures.
It's quite possible that this is because most of the thread headers are
platform-dependent, so are included through a macro expansion (e.g. the one in
boost/thread/tss.hpp). If so, is there a way to flag the dependency directly?
-- Anthony Williams Just Software Solutions Ltd - http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk