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