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

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

On Tuesday 17 June 2014 01:45:29 Julian Gonggrijp wrote:
> 
> So how about this: we work with two files. For now, let's call them
> conditional_deps.txt and deps_cache.txt. Both are optional and
> versioned if present. The conditional_deps.txt contains only
> toolset/platform annotations and is maintained by humans.

I'm ok with conditional_deps.txt.

> The deps_cache.txt contains only the "bare" header-level dependency
> information and is never maintained or even supposed to be read by a
> human (perhaps it could be hidden).

Ok.

> A commit hook is provided that
> module maintainers can opt to add to their module configuration to
> have it generated automatically (this won't affect history or be slow;
> see below).

I see two potential problems with git hooks.

1. As I understand, the hooks won't work with merging pull requests, unless 
merged manually, on the developer's machine with the hook installed.
2. AFAIK, the hooks need to be set up by developers on every local copy of the 
git repository. It is possible that someone performs a commit without running 
the hook (maybe not intentionally), leaving the cache outdated.

Both could be solved by server-side hooks, but I don't know if this is 
possible to implement with GitHub. But I suspect any such server-side hooks 
would generate commits and the need to pull after push, which would not be 
acceptable, IMHO.

Performance is also important. I'm not sure IO will necessarily be the 
limiting factor since I'm afraid you will have to perform a more elaborate 
preprocessing than grep to support inclusion repetition and header path 
combining in preprocessor. But it's too early to say anything about 
performance since there is no working prototype.

> Libraries that don't have the cache can still be handled
> "blindly", as you suggested. In release archives the cache is
> (automatically) bundled with the superproject.

Ok with that.

> > [...]
> > 
> > Another alternative is to create a new git submodule to store the cache
> > in.
> 
> I think that would be a bad idea. The cache should be directly coupled
> to the commit. We must avoid rolling our own datastructures just to
> match the right cache to the right commit.

There is a way to associate it with the commit - if the cache is stored in the 
superproject and generated when the superproject is updated to refer to the 
new commit in the submodule. The updated metadata can be committed in the same 
commit as the reference update.

> > We're discussing a mechanism that will require mass changes to the
> > libraries and possibly the workflow.
> 
> No, I think it shouldn't. My intention is to provide a new layer of
> convenience without shaking things up too much. It should make it
> easier to introduce other, more transformative changes; not the other
> way round.

Well, commit hooks (the client side ones) are a change in the workflow.