Hi, in my developement I use to include some tests that check that a header file compiles. Other boost developers do the same. How this is done now? We write a .cpp file including the header file // check_header1_compiles.cpp #include <boost/header1.hpp> and add it to the list of compile test test-suite LIB_inclusion : [ compile check_header1_compiles.cpp : : ] [ compile check_header2_compiles.cpp : : ] ... [ compile check_headerN_compiles.cpp : : ] Even if this is simple, the creation of the file is tedious. Do you know a simple way to do it? Has boost a policy about header files compilation? If not I think that we need it, and that this must be as easier to do as possible, for example by declaring the list of header files that need to pass this check. test-suite LIB_inclusion : [ check_header_compiles : header1.hpp header2.hpp ... headern.hpp : ] I have not tried to define the rule check_header_compiles using bjam, but I suppose that this is possible. Has some one already do something similar? What do you think? Vicente ----- Original Message ----- From: "Chris Newbold" <Chris.Newbold@mathworks.com> To: <boost@lists.boost.org> Sent: Tuesday, September 02, 2008 10:53 PM Subject: [boost] [thread] 1.36 thread.hpp compilation problem
I'm in the process of evaluating Boost 1.36 as a potential upgrade from 1.35, in part to get the critical fixes to Boost.Thread.
I've found, however, that something appears to have been broken with the library-level header and the way that it includes all the more-specific headers. My cursory search of the mailing list didn't reveal any previous reports; my apologies if I missed something.
Here's my one-line test program:
#include <boost/thread.hpp>
This compiles cleanly using 1.35, but with 1.36 there are a number of errors related to condition_variable::wait and shared_mutex:
<snip> -Chris