Andrey Semashev wrote:
If the tool is able to extract the information from the headers then why do we need the config files? We should minimize the amount of information to be managed by developers - to just the "optional" annotations.
I agree with this sentiment, but we need a way to cache the full dependencies that doesn't require us to change the entire structure of Boost.
I recognize that the full list of headers and dependencies might be useful for the deployment system to avoid downloading and re-parsing headers.
Yes.
But this doesn't mean this list has to be stored in git and managed by developers. You can employ the approach taken by most package managers (e.g. in Linux and OS X ports, I think). There are downloadable packages (which would correspond to sub-modules or links to their git repos) and auto-generated metadata to help resolving dependencies _prior_ to downloading anything.
Why emphasise "prior"? The user requests module X so I download X anyway. Then I can look up what X depends on, whether those data are summarized within X or somewhere outside it. Where do you store the metadata if not within the module? I like the idea of taking automatically generated data out of the versioning system, but it should be minimally invasive.
The metadata should be automatically updated when the packages are uploaded (i.e. official snapshots are uploaded or a referred git tag is added).
Do you envision this in the current situation where "packages" are loaded as sub-modules of the boost super-project, or in a new situation where the boost super-project is taken away and "packages" are standalone (but with dependencies)?
In fact, it seems to me that there is much more infrastructural work to it than just the dependency tracking tool. It would be nice to see a proposal describing how the deployment process would look like, involving the dependency tracking tool, git, Boost users and maintainers.
In a nutshell, both for users and maintainers: 1. Clone the superproject non-recursively. 2. Request specific modules to be installed by Boost.Build; dependencies are tracked by the handler tool which uses git to clone more modules. In addition, for maintainers: 3. Create/update the configuration file by running the handler tool before pushing to the public repo (this could be a git hook). 4. (Optionally) annotate the configuration file with conditional dependencies. (3 and 4 may be swapped if generated data are taken out of git.) In addition, for testers: 5. Additional test dependencies are also automatically tracked and cloned by the handler. 6. Handler verifies the configuration file as part of the test suite. The scope of what I propose does not go beyond this. -Julian