Subject: Re: [boost] date_time -> serialization (Was: spirtit -> serialization)
From: Julian Gonggrijp (j.gonggrijp_at_[hidden])
Date: 2014-06-16 05:42:58
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