Boost logo

Boost :

Subject: Re: [boost] date_time -> serialization (Was: spirtit -> serialization)
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2014-06-16 04:45:21

On Monday 16 June 2014 01:51:05 Julian Gonggrijp wrote:
> Andrey Semashev wrote:
> > On Sunday 15 June 2014 23:45:37 Julian Gonggrijp wrote:
> >> I just caught up with this discussion, and based on what I read I
> >> think the future automated dependency handler should indeed operate on
> >> a per-header basis. This would mean that the configuration file of a
> >> module would list all headers in the module, and for each header in
> >> the module list all headers that it directly depends on. Of course
> >> still with support for conditional (e.g. tool-dependent) dependency
> >> annotations. *Optional* dependencies however could then be detected
> >> automatically, as I'll explain in my inline reply below.
> >
> > Umm, I don't think that manually listing all headers and their
> > dependencies in a config file is a viable idea.
> That is not the intention. The tool generates the file for you (when
> you ask for it). The file is still there so you can annotate it with
> tool conditions. Having a single file that lists all header
> dependencies also speeds up automated downloading, because the tool
> doesn't have to traverse your 235 headers but can find all
> information in one place.
> The tool will also be able to update the file while respecting your
> annotations. It will also be invoked as a part of the regression
> tests to check that the file is complete.
> See also .
> > I have 235 headers in Log and who knows how
> > many dependent headers. Even if that information is filled once, I can't
> > realistically guarantee that the config file stays actual as I work on the
> > library.
> >
> > The list of headers and their dependencies should be inferred by the tool
> > from the headers themselves.
> Yes.

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 recognize that the full list of headers and dependencies might be useful for
the deployment system to avoid downloading and re-parsing headers. 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. The metadata should be
automatically updated when the packages are uploaded (i.e. official snapshots
are uploaded or a referred git tag is added).

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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at