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.