Re: [Boost-users] Auto-Link issues - was RC1 nvp.hpp gotcha

From: Vladimir Prus (ghost_at_[hidden])
Date: 2005-08-12 03:17:44

Robert Ramey wrote:

>>> Before implementing this rule, any program which included A.hpp would
>>> require linking with the serialization library to build.  This was
>>> provoked
>>> by the auto-linking facility.  This would occur even if serialization
>>> wasn't
>>> used in the program.  The made it amost impossible to have a
>>> "library" of classes which could be imported into various programs.
>>
>> I don't get this. Why including <serialization/export.hpp> forces
>> auto-linking? You can arrange the headers to that auto-linking is
>> enabled only if user includes headers that require cpp files, no?
>> Specifically, you should make sure that
>> boost/serialization/config.hpp (that triggers auto-linking), is not
>> included by export.hpp, either directly or indirectly.
> 
> ...\more\separate_compilation.html describes the problem.
> 
> Now if I recall, you're using gcc which doesn't support auto-linking so
> you
> would never see this problem.  This addresses the seeming endless problems
> that users have getting their projects to link with the proper version of
> the library.  <....>

Yes, I know both the problem and what's autolinking is about.

> invoke
> #pragmas which add data to the object files which indicate which libraries
> to include.  These pragmas are invoked from the auto-linking header files
> regardless of whether or not there are unresolved references to one of the
> libraries.  So just including a header file which uses auto-linking would
> trigger the requirement of a library being included in the link even
> though
> the library isn't actually used.  

Yes, sure, unless you clearly decide which headers require linking and which
not, and include the internal header with #pragma only from the header of
the first kind. Yes, it can be *extra* messy, but for
serialization/base_object.hpp or for serialization/nvp.hpp this should not
be very hard.

>>> a) I'm very much in agreement with the idea that the meer inclusion
>>> of a header shouldn't trigger the requirement of compilation against
>>> a library which isn't used.  I realize that this is only a problem
>>> on compiles which support some sort of auto-link pragma.
>>
>> I don't see how header order affects this. Can you elaborate?
> 
> In addressing this it occured to me that in the case where only a
> serialization header is included, it would be safe and desirable to skip
> over those parts of the headers which provoke auto-linking.  This seemed
> very natural.  It did imply that that any archive classes precede those
> headers.  So it seemed simple and natural to generalize the "rule" already
> required by export.hpp.  I really had in mind the usage scenario that was
> most common to me - that no header would include both archive and
> serialization headers.  I didn't occur to me that this might cause a
> problem.
> 
> The same "trick" is used by export to instantiate code for all archives
> and
> only those archives which have been previously included.  The only
> alternatives I saw were:
> a) instantiate code for all archives - code bloat.
> b) require some sort of of defines or other user indicator as to which
> archives code should be instantiated for. This would be another hoop to
> jump through.
> So I opted for identifying the list of included archives as the list for
> which code should be instantiated for.  The required that all archive
> classes precede the export.hpp.

Oh.. Okay, I think I'm starting to understand what's going on. 
1. For BOOST_EXPORT used in headers, you want the list of archive classes
2. So, you want archive headers to be included before the header that
contain BOOST_EXPORT.
3. You generalize the above requirement to "all archive headers must be
included before all serialization headers".

Is my understanding correct?

If so, then I'd say this:
1. I don't have any magic solution for "archive headers must be included
before BOOST_EXPORT" problem. One possibility would be to disallow
BOOST_CLASS_EXPORT in headers -- after all exporting makes sense only for
concrete classes (non-abstract), and so they have some code, and some .cpp
module to invoke BOOST_CLASS_EXPORT there. Another would be to
auto-register with polymorphic_archive as I've suggested previously. (Oops,
I think I forgot to reply to your last post on that topic).

2. I'm not really happy with generalization. I still believe (although may
be wrong), that including <serialization/nvp.hpp> and many other
<serialization/> headers is possible without invoking auto-linking. Since
not users want BOOST_CLASS_EXPORT at all, or want it in headers, this will
reduce the number of "what's up with header" order questions you get on
this list.

> The auto-linking headers do contain a switch to turn off auto-linking.
> Perhaps even more attractive might be that this header inclusion rule be
> dependent on whether auto-linking is supported.  On the gcc compiler -
> this
> would always be off.   The concerns I would have about this are:
> a) it might mean an extra layer of complication in the serializaton
> headers

Sorry, but it seems that the BOOST_CLASS_EXPORT issue exists regardless of
auto-linking, no?

> This is making my head hurt.
> 
> So I'm not insensitive to your concerns.  Its just that, like everything
> else, something simple ( just implement auto-link)
> a) turns out to be alot more complex than it starts out. Autolink for
> serialization required treating 3 separarte but inter-related modules.
> b) has non-obvious, non-trivial side-effects.
> c) is a lot more work that it would seem.
> 
> Writing this makes the issues a lot clearer in my own mind and I will take
> another look at it.

And seems I've finally understood your rationale.

- Volodya