From: Hartmut Kaiser (hartmut.kaiser_at_[hidden])
Date: 2007-05-04 19:58:45
> 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
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk