Boost logo

Boost :

From: Hartmut Kaiser (hartmut.kaiser_at_[hidden])
Date: 2007-05-04 20:01:44


 
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_at_[hidden]]
> Sent: Friday, May 04, 2007 6:59 PM
> To: 'boost_at_[hidden]'
> 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
>


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk