Re: [boost] Hybrid compilation model? was: [system] Why is this not header-only?

From: Ulrich Eckhardt (doomster_at_[hidden])
Date: 2007-04-07 03:13:33

On Friday 06 April 2007 16:57, Beman Dawes wrote:
> Some users prefer the header-only approach. They need to be able to
> quickly set up at new project without messing around with compiled
> libraries. They want to be able to evaluate Boost libraries without
> doing any preparatory work altogether.
>
> Jeff Garland and Andrey Semashev argued that Boost should adopt a hybrid
> compilation model that allows applicable Boost libraries to be used in
> either header-only or compiled-library modes. 
[...]
> I'll like to challenge Boosters to think about this problem a bit more,
> and I'd love to see someone who understands the challenges take, say,
> Boost.System and demonstrate how it could be packaged for either
> header-only or compiled-library use.

I wrote a mail describing a way in said thread. This is not a header-only 
approach though, and it aimed at Boost.Thread not Boost.System. Instead of 
the header-approach, it simply supplies a single sourcefile that in turn 
#includes all other necessary sources to compile the library in-place.

> The important goal would be to abstract what to done into a general set
> of guidelines (and any configuration support needed). In other words,
> we don't so much need a solution for Boost.System as for any Boost
> library that would benefit from a hybrid computation model.

Guidelines:
- Every library that needs separately compiled sources (Thread, System, 
Regex, ..) should provide an additional file in the include directory named 
e.g. "compile_in_place.cpp" (I don't care for the name, but it should be the 
same for all libs). For Thread, that would be 
boost/thread/compile_in_place.cpp".
- This file in turn includes all required sourcefiles for that library.
- If several sourcefiles of a library use anonymous namespaces or file-static 
functions, those need to be checked against conflicts. It might be sufficient 
to guard those parts with include guards, in particular when they are already 
in a common file like with Boost.Threads.
- Generally, the compilation mode must be configured for static linking (in 
fact it's just a static library that is compiled 'in-place'). For compilers 
that support it, autolinking needs to be turned off because there is no .lib 
file and that would lead to errors. I'm afraid that this needs to be done by 
the user via a macro, and I think this macro even already exists.
- If functionality can't be achieved (IIRC thread-specific storage without 
DLLs was believed to be impossible), it should be documented as unavailable. 
Optionally, we could try to cause compile-errors when using such stuff, but 
that requires that we know that this-or-that lib is 'compiled in-place', 
which again requires the user to set some macro. Until now, I'd just 
say "sorry" and leave it at linker errors and documentation.

Note: this means that the same source will be compiled in a plethora of 
different environments, and not just the one explicitly setup by Boost. 
Ideally, it shouldn't matter. Practically, it will have to cope with e.g. 
NOMINMAX not being defined on win32 and similar things. Additional checks 
might be necessary to make the code resistant to such things, but it is 
generally feasible. I would then also simply generate an error if some 
preconditions are not met by the environment. In return you solve all 
problems that are caused by compilers generating differing ABIs, which is 
IMHO much nastier to diagnose.

Uli