Boost logo

Boost :

From: Rene Rivera (grafik.list_at_[hidden])
Date: 2006-04-12 16:01:34

Roland Schwarz wrote:
> 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
> 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.

Yes, that would be why it's catching the header change.

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

The flaw in that rational is that many other Boost libraries are "users"
of other Boost libraries. So not having the dependency chains work
causes problems during testing because dependent libraries are then not
retested when dependencies change.

> 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 believe that is what other libraries that do, or something similar.
It's not even needed to have the "#if 0", the headers could be mentioned
in a comment. Just as long as they look like valid #include's:

/* For build dependency:
#include <boost/thread/pthread/condition.hpp>
#include <boost/thread/win32/condition.hpp>

More informative comment would be good of course.

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

Understood :-) I was just bringing up some issues that have come up in
the past due to such use of macro includes.

-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. -
-- rrivera/ - grafik/
-- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

Boost list run by bdawes at, gregod at, cpdaniel at, john at