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