[boost] [repost][serialization] autolinking

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

Allow me to repost a digest of my last two messages about the
issue of autolinking in Boost.Serialization. If the final decision
is to *not* adhere to my proposed policy, I'd be grateful to know
asap, so that I can hack my way in my own source code. Thank you,

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

-----------------------

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.

If (A) is honored, autolinking will be triggered only when including
boost/archive/*.hpp headers, which IMHO is just fine, since these are
a sure sign that the user (not the 3rd party library) is explicitly
requesting
serialization capabilities and will welcome the autolinking stuff.

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.