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
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
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