[boost] Re: Include only one Boost file

From: Dan'l Miller (optikos_at_[hidden])
Date: 2002-06-26 08:10:21

  from Maciej Sobczak <maciej_at_[hidden]>:
> put appropriate 
> #include in my code and happily distribute the whole project.
> 
> No, no, no...
> 
> The timer.hpp #includes config.hpp and limits.hpp, which...
> Again - my compilers can eat the class timer without problems and I do 
> not expect porting soon to some esoteric or more broken compilers.
> 
> 1. Including the whole config/details/limits hierarchy in my little 
> project is not justified (it would be bigger than the project itself).
> 2. Asking my users to download the whole Boost so that I can use one 
> little simple timer class is not justified.
> 3. Writing code like:
> 
> #define BOOST_NO_USER_CONFIG
> #define BOOST_NO_CONFIG
> #define BOOST_NO_whatever_else_to_cut_the_includes
> #define BOOST_NO_...
> // and finally:
> #include "timer.hpp"
> 
> is not justified (or is it?).
> 
> I understand the need for all those configs/details/limits and so on, 
> but portability to everything is not my concern here and my project is 
> supposed to be as simple as possible.

  I also go through similar activities with Boost.  I wish to release a subset of Boost to a larger community in an effort to censor what I consider to be the less-desirable portions of Boost, so that there is a clear statement of which portions of Boost are approved within a code base and which portions are strongly discouraged for whatever reason.  Hypothetically, let us assume that the only subset of Boost which I want to remain uncensored is the Boost Graph Library.  (I.e., I want hypothetically to censor some variation of "the rest of Boost" other than BGL.)  In the current state of affairs, at each release of Boost, I manually copy out the subset and its dependencies as determined by #include statements in the subset, then delete the rest.

  The reasons for censorship might be:

  1) The library is still in upheaval.  Allow more time for the library to settle down before a million lines of code start depending on some soon-to-be-antiquated version of the library.

  2) The library is maldesigned or misses the point.  Replace the library with a better-designed alternate (e.g., one which was designed by a wise overseeing sage; one which was not designed by committee).

  3) The library's very reason to exist is disgusting.  Prohibit its use.

  4) The library is a distracting alternate/hi-jacked knock-off of a library, divergent from the primary author of that library.  This occurs when a source base is forked, such as by two camps wanting to take the software in different directions (e.g., Stallman's GNU Emacs versus XEmacs).  At first XEmacs might be declared by some people to be the distracting knock-off, but over the years which branch becomes the dominant conveyor of the open-source product can become less & less clear, as it has with GNU Emacs versus XEmacs (both of which have effectively displaced the prior Gosling Emacs and TECO Emacs in analogous survival-of-the-fittest/most-popular Darwinism).

  It would be quite nice for me and for Boost submissions for C++0x standardization if there were to exist a Boost subsetting tool (or build target) which extracted a subset of Boost and that subset's dependencies.  Forgetting about me for a moment, Beman et al could use such a tool to pull out certain libraries for submission to C++0x standardization, leaving others behind.  At release x, Beman et al could pull out say, BGL & its dependencies, leaving the rest of Boost behind.  Then at release x+1, Beman et al could pull out some other subset of Boost, leaving BGL behind (because it was submitted last time).

  In direct response to the original poster, I would recommend dividing your Boost-using project's source base into two categories: 1) code which your organization authors itself and 2) code which arrives at your organization from a third-party (e.g., COTS vendor, Boost, GNU).  Then *none* of the Boost code becomes part of your project's source code.  Then the third-party code is available for multiple projects.  If using CVS or ClearCase or similar revision control system with labeling/tagging, you can then apply a label to each release x of each 3rd-party unit of software and then use only that label to build your project until you upgrade your project to adopt some later release (regardless of whether that later release is x+1 in the near term or x+37 years from now), even if you check in other revisions of that 3rd-party unit of software.  Because your project as identified a particular label/tag as the revision to use, your project ignores prior and later labels/tags.  If you keep the compiler version t
he same by strict unchanging label/tag identifier, the build environment the same by strict unchanging label/tag identifier, the 3rd-party library/framework-infrastructure the same by strict unchanging label/tag identifier, and your project's source code the same by strict unchanging label/tag identifier, then you can build your project without software-rot years into the future.  (The industry in which I work is founded on this principle of being able to rebuild a software load exactly as it was built up to 20 years ago using this technique.)  Rather than figuring out ways of directly modifying Boost (by your editing effort or by some lobbying-Boost effort), I would recommend treating Boost as any other 3rd-party: contain/quarantine each unit of 3rd-party software so that its identity, its overall lifetime, its per-release stages of life, and the on-going decision-making of a group of people who are outside of your control so that changes in identity, ending of lifetime, beginning of a reborn lifetime, and 
any on-going 3rd-party decision-making do not jerk around your source code base until you overtly decide to change the label/tag to pick up those changes.

  By the way, this subsetting is another form of Boost installation.  Contrary to criticisms of too many categories of build-for-install and build-for-development in my proposed WWW-site submission a while back for describing the autotools adjunct build, I think that my list was too small, not too big, as it would contain an install-a-subset category or two.  In that list of categories, the number/decomposition of categories is based in reality, not on whim.  Rejecting those categories implies rejecting their accurate description of  reality which in turn implies rejecting that portion of reality.  The reality of submitting portions of Boost to C++0x standardization (as well as the reality of some people like me wanting to censor portions of Boost) exists.  One can either choose to accept reality or invent a fiction inside one's imagination.