Rene Rivera schrieb:
How about:
#ifdef __WIN32__ #include <win32/myfile.hpp> #elif ... ... #endif
So that dependency analysis works with Boost.Build without yet more special case kludges ;-)
I adopted #define PLATFORM_HEADER(header) <PLATFORM_HEADER_DIRECTORY/header> Interestingly the Boost.Build seems so smart that it _does_ recognize if a header has changed. Hmm, while thinking about this I am not sure if it really is, since I might have referenced the include from the corresponding src files explicitely. But even if so, for library writers this will pose no problem since they simply have to reference the platform headers explicitely rather than by computed include. At least the src files are platform dependant too. For user code on the other hand this never is a problem since the headers just reference library code. And I think it is not too much a problem to force a rebuild if the library has been changed. Another idea to overcome this problem: There could be a include header that lists all platform headers say: #if 0 #include <boost/thread/pthread/condition.hpp> #include <boost/thread/win32/condition.hpp> #endif This will do no harm to the compiler and keep the dependency generation happy. What do you think? I already checked in code that uses the macro, in the boost rewrite branch. However I would prefer a boost macro that lives in boost.preprocessor. Boost.config on the other hand could be extended so that the platform chooser also provides a reusable macro that could be used in the following manner: #include BOOST_PLATFORM(thread, condition.hpp) and would expand into: #include <boost/thread/linux/condition.hpp>
And so that people with smart text editors can select the include file and open it directly. And so that other people reading the code have a chance at understanding it.
Yes, but this comes at the cost of lot of boiler plate code. And if you want to change the logic of the platform chooser you will need to change all this code too. Roland