On 27 June 2016 at 15:39, Rafael Espíndola <rafael.espind...@gmail.com> wrote: > So, I probably missed something, but what was the main objection to > just using submodules? This would put llvm inside clang instead of the > other way around. When changing an API one currently has to
I don't think the consensus was to change the order of inclusion (llvm into clang), but to *not* change anything else at this stage. That's one of the reasons the umbrella project with sub-modules was the most accepted solution, because we can later change the inclusion order (if we all agree, etc), without changing the underlying storage. > * Change llvm. > * Change clang and in the same atomic commit change what revision the > submodule points to. Having one repository inside another was rejected due to the problems it brings for development, validation and release. James has just pointed a few of those problems for development. An umbrella project with a commit hook and an auto-update would make sure all commits are synchronised correctly. Though, indeed, this will mean we'll still have the trouble of buildbots picking up one commit and not the other, I don't think this is a big enough problem that we should mess up everyone's workflow. cheers, --renato _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
