Re: [boost] library dependencies

From: Jeff Garland (jeff_at_[hidden])
Date: 2007-05-04 20:11:55

Hartmut Kaiser wrote:
> 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.

This isn't a new debate, but I believe a separate user specified header is the 
correct solution.  This is how date-time is done and others should be as well. 
  As I recall prior discussions, not all libraries have been factored that way 
-- I think multi-index isn't -- Joaquin had some good reasons. Anyway, it's a 
bit more effort, but because of the serialization design it should always be 
possible do have external serialization functions. In general serialization 
requires a pile of extra includes that should be avoided if 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.

Seems to me that unless it's essential to library function serialization 
support should always be turned off by default.

Jeff