Rene Rivera <grafikrobot@gmail.com> 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 mismatch.

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 -- 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

Anthony Williams wrote:

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?

Exactly, if you include via: #include SOME_HEADER then bjam can't trace the dependencies, one trick would be to have a code block: #if 0 // This block is for header dependency scanners: # include <a.hpp> # include <b.hpp> #endif at the end of the header to ensure that the dependencies get tracked correctly. There are some (undocumented) Boost.Build options you could use as well, but the header approach is easier and will work with other tools besides bjam that scan dependencies the same way. HTH, John.

"John Maddock" <john@johnmaddock.co.uk> writes:

Anthony Williams wrote:

...

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?

Exactly, if you include via:

#include SOME_HEADER

then bjam can't trace the dependencies, one trick would be to have a code block:

#if 0 // This block is for header dependency scanners: # include <a.hpp> # include <b.hpp> #endif

at the end of the header to ensure that the dependencies get tracked correctly.

Thanks. I've changed the includes so they are directly conditional rather than hidden in a macro. Anthony -- 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