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

From: Robert Ramey (ramey_at_[hidden])
Date: 2005-08-11 10:54:11

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