[boost] Re: [repost][serialization] autolinking

From: Robert Ramey (ramey_at_[hidden])
Date: 2005-05-25 11:02:40

Its not a policy that including serialization trigger autolinking.  If it
currently does, it contravenes my intention.  When I last looked at this I
wasn't convinced this was actually happening.  I took precautions to avoid
this and felt it was addressed.  Your detailed investigation motivates me to
look again and more carefully.  It is also helpful for showing me where to
look.  I'll do this.  Thanks for sheding light on this.

I've been a little bogged down in this area as now the auto-linking of DLLS
on vc6 and vc7 stopped working.  I'm not sure why this is.  Its only a
problem on with these compilers.  I'm still bogged down on this.

Robert Ramey

P.S. The local macro IMPORT is to trigger the autolinking for DLL import
library.  I'm sort of suspicious of this as I made a change here to address
a problem when compiling from the VC IDE.

RR

Joaquín Mª López Muñoz wrote:
> 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.
>
>
>
>
>> _______________________________________________
>> Unsubscribe & other changes:
>> http://lists.boost.org/mailman/listinfo.cgi/boost