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