Re: [boost] date_time -> serialization (Was: spirtit -> serialization)

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