[boost] Does Boost really need to be put in object libraries?

From: Daryle Walker (darylew_at_[hidden])
Date: 2003-11-13 04:23:45

Before I state my opinion, note that:
    1. I don't use Boost for "real" work, just to make other (potential)
Boost libraries
    2. The only mandatory-source Boost component I use is the test library.

With the whole Boost-build sub-project and the recent thread about "Draft
Tutorial / Guidelines for Authors of Boost Libraries Containing Separate
Source," I guess that a lot of users set up Boost as a _separate_ library,
either static or a DLL.

Is that really necessary?  I just stick all the mandatory-source I need into
the project file with the program-specific code and let the compiler do its
magic.  This way, I don't have to mess with different compiler and/or linker
options.  Wouldn't that be an easier solution?

The problems would be:
1.  There's at least one combination (Boost.Thread on Windows) that requires
a DLL.  There's no way around that.
2.  If there's some maximum limit of source files listed in the project
file, or object files that can be statically unified, then a split must
occur.
3.  You really want "conserve" space by having only one copy of the compiled
Boost (either static and/or dynamic, in a common location).  You have to
watch out that you need your "one" copy for _each_ compiler/linker setting
combination, and you have to give each combination an easy-to-decode name.
(Also, with static libraries, the final product gets a separate copy anyway.
If you're using Boost CVS, you have to remember rebuild the library after
each update, in a separate step, before you update/rebuild your specific
programs.)

If the difficulty is just finding the mandatory-source files, then we could
re-consider moving those files to a "BOOST_ROOT/boost_src" directory, to
make them easier to locate and add to a project file (just select-all then
drag-and-drop).  We would have to make sure to keep the file names fairly
clear.

How many mandatory source files do we have anyway?  Are there any with
shared names?  What about names that are vague once they're put in a common
directory?  Shouldn't we sub-divide the unified directory (if it's done)
according to namespaces?

Daryle