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).
> 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
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.