Re: [boost] Re: [serialization] autolinking

From: Joaquín Mª López Muñoz (joaquin_at_[hidden])
Date: 2005-05-23 04:49:25

Joaquín Mª López Muñoz ha escrito:

> I humbly request that you reconsider your design so that the following
> guarantee is honored:
>
> * (A) Any code including *only* boost/serialization/*.hpp headers won't
> trigger autolinking of Boost.Serialization.
>
> The following is a rationale for this policy: a 3rd party library that
> provides *intrusive* serialization capabilities will most likely need
> to include some of boost/serialization/*.hpp. If those headers
> trigger autolinking, the user will face the annoying fact that
> Boost.Serialization is autolinked even if she didn't explicitly try
> to use serialization at all.
> Granted, if the serialization capabilities of the 3rd party library
> are not taking advantge of, autolinking will ultimately have no effect
> on the final binary, but the point is that the user will be forced nonetheless
> to have the Boost.Serialization lib built and available. This is most
> unfortunate in the case the 3rd party library is a header-only lib,
> since the user may very well be using it without having built anything
> from Boost. This is exactly what's happening now with Boost.MultiIndex.
>
> Autolinking is triggered by the (implicit) inclusion of
> boost/serialization/config.hpp. This header is in turn included by
> void_cast.hpp and extended_type_info.hpp, and if you pull out from this
> thread it turns out virtually any boost/serialization/*.hpp header will
> trigger autolinking.
> To honor (A), you just have to remove the inclusion of
> boost/serialization/config.hpp by the aforementioned void_cast.hpp
> and extended_type_info.hpp. From what I can see, the inclusion
> is done so as to bring in the definition of BOOST_SERIALIZATION_DECL,
> so in principle having this macro defined in a separate header would suffice.
>

I have inspected the source code and looks like autolinking is triggered in
three points:

boost/serialization/config.hpp
boost/archive/detail/auto_link_archive.hpp
boost/archive/detail/auto_link_warchive.hpp

So, it seems like my proposal boils down to removing autolinking from
the first header. As a proof of concept, I've done so (see attached modified
source); with this changes in place, my local tests seem to indicate that:
  * Autolinking does not kick in if including only boost/serialization/*.hpp
headers.
  * Autolinking still works if including any of boost/archive/*.hpp.
boost/serialization/config.hpp has a local macro named IMPORT whose
semantics escapes me, so I might be missing something.

Thank you,

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo