Re: [boost] [modularization] proposal and poll

Subject: Re: [boost] [modularization] proposal and poll
From: Julian Gonggrijp (j.gonggrijp_at_[hidden])
Date: 2014-06-09 12:25:12

Julian Gonggrijp wrote:

> [...]
> 
> 
> PROPOSAL
> 
> The following (evolutionary) global changes to Boost should be planned
> and given priority over any other proposals [e.g. 5], in the following
> order:
> 
> 1. Reduction of dependencies between Boost libraries.
> 2. Simple but effective automation of dependency handling.
> 
> 
> POLL
> 
> I think it may be easier for the steering committee to justify any
> decision on this proposal, if they have hard statistics about the
> amount of support it receives. Therefore, I invite every opinionated
> person reading this to reply with a vote, either in favour of the
> proposal or against it. I invite you to do this even if you do not
> feel the need or find the time to provide arguments for your position.
> You can later re-vote if you change your mind.
> 
> I will count the votes, and when there are more than 30 I will start
> posting the statistics occasionally. Votes are public so everyone can
> verify my data when necessary. Anyone, including the steering
> committee, can then use the numbers however they choose.

Much less than 30 (explicit) votes have come in but this thread seems
to have come to an end, so it is time for a closing report.

There is strong and unanimous support for part 1 of the proposal. I am
delighted that several people are currently fanatically working on
dependency reduction. :-)

Part 2 also found strong support, although it faced more reservations.
This is in part due to the lack of a draft implementation. I plan to
write that draft as soon as I find the time (this may take in the
order of months).

My current idea about the automated dependency handling tool is as
follows.

 - The dependency tool will use or adapt Peter Dimov's boostdep tool
   to list direct dependencies for a single module at a time.
 - Each module will contain a single, small, static, versioned
   configuration file which lists the direct dependencies in the same
   way that the tool does.
 - Dependencies listed in the configuration file may have annotations
   to mark dependencies that are tool-specific or optional. For the
   time being, these annotations will not be added automatically.
 - The configuration file may initially be generated using the
   dependency tool (without annotations), or written by hand.
 - The configuration file may be updated both by hand and by running
   the dependency tool, which extends the file with any new
   dependencies that may have come up and prunes any dependencies that
   have been removed. Pre-existing annotations will be preserved
   (unless a dependency is pruned).
 - The dependency tool will run as part of the test suite to verify
   that the configuration file is complete. Of course this check can
   also be run separately.
 - The dependency tool will run as part of the bootstrap script and/or
   Boost.Build to automatically and recursively clone dependencies
   when needed. This can also be done separately.
 - Verification and cloning will be tool-aware.
 - Optional dependencies are ignored, they can still be cloned by
   explicitly requesting them as targets.
 - Handling of tool-specific and optional dependencies, as well as the
   corresponding annotations in configuration files, will be
   implemented after the other features.

Feedback is welcome.

Cheers, Julian