One more thing. I just had a look at the Wave code. By default serialization support is switched off. So serialization dependencies are generated only if you explicitly specify BOOST_WAVE_SERIALIZATION=1. Regards Hartmut
-----Original Message----- From: Hartmut Kaiser [mailto:hartmut.kaiser@gmail.com] Sent: Friday, May 04, 2007 6:59 PM To: 'boost@lists.boost.org' Subject: RE: [boost] library dependencies
Stefan,
Appologies from me, too, as now we are getting even further from the original topic.
I have seen at least one case where it was indeed X.hpp that introduced the dependency to serialization code. However, this generates another problem:
If X is usable without serialization, users shouldn't be forced to also link to the serialization library, just because of this dependency. (In the particular case I have in mind this dependency was controlled by a preprocessor macro. That's not very practical, since packagers surely won't provide two sets of packages for X, one with and one without this dependency.)
Thus, I'd suggest to encapsulate the X-serialization functionality into a separate library (may be header-only), such as X_serialization.hpp etc. Then I can still use X stand-alone, and drag in the rest whenever I need it.
I'm not sure, if this is always possible.
PS: the library I'm thinking of is boost.wave, and there serialization was dragged in whenever BOOST_WAVE_SERIALIZATION is defined.
As far as Wave is concerned, the mentioned macro has no influence on the code generated for the library. You always can define BOOST_WAVE_SERIALIZATION to zero when compiling your code, even if the library was compiled with BOOST_WAVE_SERIALIZATION=1. The generated library has no dependency on Boost.Serialization.
HTH Regards Hartmut