Auto-Link issues - was RC1 nvp.hpp gotcha
Vladimir Prus wrote:
The statement "I believe that this rule should be very easy to follow" is definately true. I'm quite sure I know what I believe.
Oh ;-) I kinda though that "I believe" is just a polite way of making a statement.
I mean to say that this is my opinion. I really do mean that, as far as I know, based on my personal experience, demos, and test cases I believe that organizing code subject to this rule/restriction shouldn't be difficult. I also mean that I'm open to be proved wrong via counter example. And the submission of such a counter example won't be taken personally in any way.
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. The solution - auto-linking is that macros in the code 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. I believe this issue would occur with any of the libraries which support auto-linking. I don't know if its an issue with other libraries. I would expect it to be an issue only with libraries which require that headers be included from within other headers.
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. Now it has come about that this creates its own set of inconveniences for some applications. There's your case, and another has brought up precompiled headers. 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 which support auto-linking. I had to spend a significant amount of time to get this right and I don't relish making it more elaborate. b) It would mean that a program which used serialization on one platform (e.g. gcc) would not support auto-linking when moved to a platform which had auto-linking available. As I write this, this wouldn't be so bad - just one more section to the manual (the gotcha section) indicating that auto-linking should be suppressed via compile time define when the application is moved. Now someone has raised the issue of pre-compiled headers - which is a feature that as far as I know is only available on borland and Microsoft compilers which also support auto-linking. 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. Robert Ramey