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

From: John Maddock (john_at_[hidden])
Date: 2003-11-14 07:35:41

> 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?

Please note that the recent thread was about guidelines for Boost authors,
not users, we need a separate document for end users (on my TODO list).

I do it your way as well: but only when working on Boost sources.

Basically if your working on the cvs then rebuilding the libraries every
time you do a cvs update is a major pain in the you know what, on the other
hand if you're working with the released version (and most end users are),
then one rebuild every six months or so is a lot easier to manage.

> 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.

Ditto for the Python source.

> 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.

It's been suggested before, but never really took off :-(

> 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?

No according to library, as for what we have there is:

libs/filesystem/src/convenience.cpp
libs/filesystem/src/exception.cpp
libs/filesystem/src/operations_posix_windows.cpp
libs/filesystem/src/path_posix_windows.cpp
libs/graph/src/graphviz_digraph_lex.cpp
libs/graph/src/graphviz_digraph_parser.cpp
libs/graph/src/graphviz_graph_lex.cpp
libs/graph/src/graphviz_graph_parser.cpp
libs/python/src/aix_init_module.cpp
libs/python/src/dict.cpp
libs/python/src/errors.cpp
libs/python/src/list.cpp
libs/python/src/module.cpp
libs/python/src/object_operators.cpp
libs/python/src/object_protocol.cpp
libs/python/src/str.cpp
libs/regex/src/c_regex_traits.cpp
libs/regex/src/c_regex_traits_common.cpp
libs/regex/src/cpp_regex_traits.cpp
libs/regex/src/cregex.cpp
libs/regex/src/fileiter.cpp
libs/regex/src/instances.cpp
libs/regex/src/posix_api.cpp
libs/regex/src/regex.cpp
libs/regex/src/regex_debug.cpp
libs/regex/src/regex_synch.cpp
libs/regex/src/w32_regex_traits.cpp
libs/regex/src/wide_posix_api.cpp
libs/regex/src/winstances.cpp
libs/signals/src/connection.cpp
libs/signals/src/signal_base.cpp
libs/signals/src/slot.cpp
libs/signals/src/trackable.cpp
libs/smart_ptr/src/sp_collector.cpp
libs/smart_ptr/src/sp_debug_hooks.cpp
libs/test/src/cpp_main.cpp
libs/test/src/execution_monitor.cpp
libs/test/src/supplied_log_formatters.cpp
libs/test/src/test_main.cpp
libs/test/src/test_tools.cpp
libs/test/src/unit_test_log.cpp
libs/test/src/unit_test_main.cpp
libs/test/src/unit_test_monitor.cpp
libs/test/src/unit_test_parameters.cpp
libs/test/src/unit_test_result.cpp
libs/test/src/unit_test_suite.cpp
libs/thread/src/condition.cpp
libs/thread/src/exceptions.cpp
libs/thread/src/mutex.cpp
libs/thread/src/once.cpp
libs/thread/src/recursive_mutex.cpp
libs/thread/src/thread.cpp
libs/thread/src/threadmon.cpp
libs/thread/src/tss.cpp
libs/thread/src/xtime.cpp
libs/date_time/src/gregorian/date_generators.cpp
libs/date_time/src/gregorian/greg_month.cpp
libs/date_time/src/gregorian/greg_weekday.cpp
libs/date_time/src/gregorian/gregorian_types.cpp
libs/date_time/src/posix_time/posix_time_types.cpp
libs/python/src/converter/arg_to_python_base.cpp
libs/python/src/converter/builtin_converters.cpp
libs/python/src/converter/from_python.cpp
libs/python/src/converter/registry.cpp
libs/python/src/converter/type_id.cpp
libs/python/src/object/class.cpp
libs/python/src/object/enum.cpp
libs/python/src/object/function.cpp
libs/python/src/object/inheritance.cpp
libs/python/src/object/iterator.cpp
libs/python/src/object/life_support.cpp
libs/python/src/object/pickle_support.cpp
libs/thread/src/mac/delivery_man.cpp
libs/thread/src/mac/dt_scheduler.cpp
libs/thread/src/mac/execution_context.cpp
libs/thread/src/mac/init.cpp
libs/thread/src/mac/os.cpp
libs/thread/src/mac/ot_context.cpp
libs/thread/src/mac/remote_call_manager.cpp
libs/thread/src/mac/safe.cpp
libs/thread/src/mac/scoped_critical_region.cpp
libs/thread/src/mac/st_scheduler.cpp
libs/thread/src/mac/thread_cleanup.cpp
libs/mpl/preprocessed/src/advance_backward.cpp
libs/mpl/preprocessed/src/advance_forward.cpp
libs/mpl/preprocessed/src/and.cpp
libs/mpl/preprocessed/src/apply.cpp
libs/mpl/preprocessed/src/arg.cpp
libs/mpl/preprocessed/src/basic_bind.cpp
libs/mpl/preprocessed/src/bind.cpp
libs/mpl/preprocessed/src/fold_backward_impl.cpp
libs/mpl/preprocessed/src/fold_impl.cpp
libs/mpl/preprocessed/src/full_lambda.cpp
libs/mpl/preprocessed/src/iter_fold_backward_impl.cpp
libs/mpl/preprocessed/src/iter_fold_if_impl.cpp
libs/mpl/preprocessed/src/iter_fold_impl.cpp
libs/mpl/preprocessed/src/lambda_helper.cpp
libs/mpl/preprocessed/src/lambda_no_ctps.cpp
libs/mpl/preprocessed/src/list.cpp
libs/mpl/preprocessed/src/list_c.cpp
libs/mpl/preprocessed/src/or.cpp
libs/mpl/preprocessed/src/placeholders.cpp
libs/mpl/preprocessed/src/template_arity.cpp
libs/mpl/preprocessed/src/vector.cpp
libs/mpl/preprocessed/src/vector_c.cpp

But that's not necessarily a correct list :-)

John.