<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jul 28, 2016, at 7:32 PM, Lang Hames <<a href="mailto:lhames@gmail.com" class="">lhames@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div style="font-size:13px" class="">Hi Mehdi,</div><div style="font-size:13px" class=""><br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">This a narrow view IMO: the criteria #1 Chris mentioned to include projects in the monorepo was " must be tightly coupled to specific versions”. <br class="">It means that even with the test suite (and possibly some runtime) out of the monorepo, all the software that is tightly coupled would be in the monorepo, and that alone would be enough to alleviate the needs for (most of the) tooling/infrastructure.</blockquote><div style="font-size:13px" class=""><br class=""></div><div style="font-size:13px" class="">Fair point, but coupling isn't binary: even the test-suite is coupled to the versions of clang that can compile it, it's just relatively loose compared to LLVM/clang. </div><div style="font-size:13px" class=""><br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">I find it a fairly different scale to clone 3 repos on a bot versus having to keep multiple repositories *in sync* (i.e. cross repository synchronization).</blockquote><div style="font-size:13px" class=""><br class=""></div><div style="font-size:13px" class="">I think it depends on the nature of the tools that are required. Bots are relatively simple since they're only reading from the repos, not writing. They're not the only use-case I have in mind though.</div><div style="font-size:13px" class=""><br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Different problems, different tools… I’m against artificially creating “problems" for upstream developers only because the tooling to solve them works for downstream users.</blockquote><div style="font-size:13px" class=""><br class=""></div><div style="font-size:13px" class="">I don't think these are actually different problems: I would guess that the problem of collecting some subset of the LLVM projects into a usable source-tree is shared by many downstream users, and it's common in my workflows (e.g. just checking out llvm and lld). It will have to be solved by someone, since downstream users need it even if we adopted a mono-repo.</div></div></div></blockquote><div><br class=""></div><div>What I meant by “different problem" is that “downstream users” for instance don’t need to commit, that makes their problem/workflow quite different from an upstream developer (for instance it is fairly easy to maintain a read-only view of the existing individual git repo currently on <a href="http://llvm.org" class="">llvm.org</a>).</div><div><br class=""></div><div>Also while we can create scripts for (almost) every scenarios, one have to put in balance the script that is run once at checkout time vs the set of scripts required for day-to-day development: for example what if I want to switch my tree to my work-in-progress branch where I changed a LLVM library to use the new "Error checking” API and adapted all the other projects that using this API, and then I want to rebase this branch on master for every projects so that I can get ready to push. My impression is that a single repo makes this use-case trivial with a standard set of git commands.</div><div><br class=""></div><div><div>I believe a repo like <a href="https://github.com/llvm-project/llvm-project" class="">https://github.com/llvm-project/llvm-project</a> solves most of the workflows (both for developers and downstream users) with little to no tooling required. Providing a read-only export from this repo is also fairly easy, and can be done asynchronously in a deterministic way (contrary to the submodule umbrella update that requires some server-side hooks). </div><div>The only two unanswered drawbacks that I got from this thread are:</div><div class=""><br class=""></div></div><div>1) A "<span class="" style="white-space: pre-wrap; background-color: rgb(255, 255, 255);">major drawback of a single huge repo IMHO: </span><span class="" style="white-space: pre-wrap; background-color: rgb(255, 255, 255);">In git, to push a commit you must have it at the remote HEAD. </span><span class="" style="white-space: pre-wrap; background-color: rgb(255, 255, 255);">If HEAD has changed you need to rebase/rebuild/retest/retry. </span><span class="" style="white-space: pre-wrap; background-color: rgb(255, 255, 255);">With a single monster repo, a commit to 'lld' means I have to </span><span class="" style="white-space: pre-wrap; background-color: rgb(255, 255, 255);">go through this pain to put in my 'clang' tweak.</span><span class="" style="white-space: pre-wrap;">”, <a href="http://lists.llvm.org/pipermail/llvm-dev/2016-July/102656.html" class="">http://lists.llvm.org/pipermail/llvm-dev/2016-July/102656.html</a></span></div><div><div>2) Chris Bienemann: What about a *contributor* only wanting to contribute to compiler-rt? He has to pay the price of cloning the full repo. <a href="http://lists.llvm.org/pipermail/llvm-dev/2016-July/103052.html" class="">http://lists.llvm.org/pipermail/llvm-dev/2016-July/103052.html</a></div><div class=""><br class=""></div><div class="">I haven’t seen a good answer for 1), and for 2) it’ll come down to a balance of “how much a burden it is in 2016 to download 500MB once to contribute to a project”, and how many people (and number of commits) does this represent?</div><div><br class=""></div></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div style="font-size:13px" class=""> A shared solution (if it's possible) may be an opportunity to both share infrastructure with downstream projects and adopt a more modular approach to the LLVM project sources.</div></div></div></blockquote><div><br class=""></div><div>I had the impression that the current situation is that sources are “modular”, and that’s painful when you work cross-projects (luckily I have been focused on LLVM itself lately…).</div><div>On the opposite of a “more modular approach to the LLVM project sources”, I’d favor a goal toward "a more coherent approach to maintaining the LLVM projects sources”.</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div style="font-size:13px" class="">I'm staying deliberately light on specifics here. As I said I don't have strong feelings yet -- I'm still digesting all the ideas in this thread.</div></div></div></blockquote><div><br class=""></div><div>The other thread on the submodules proposal driven by Renato has also a lot of ideas/workflow descriptions if you’re looking for inspiration.</div><div><br class=""></div><div>— </div><div>Mehdi</div><div><br class=""></div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div style="font-size:13px" class=""> To the extent that I have a gut feeling though, this feels like it introduces very strong coupling between LLVM project sources (more than is required by the projects APIs) for the sake of convenience, so I'm trying to consider the alternatives.</div><div style="font-size:13px" class=""><br class=""></div><div style="font-size:13px" class="">Cheers,</div><div style="font-size:13px" class="">Lang.</div><div style="font-size:13px" class=""><br class=""></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Thu, Jul 28, 2016 at 6:41 PM, Mehdi Amini <span dir="ltr" class=""><<a href="mailto:mehdi.amini@apple.com" target="_blank" class="">mehdi.amini@apple.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><br class=""><div class=""><span class=""><blockquote type="cite" class=""><div class="">On Jul 28, 2016, at 6:23 PM, Lang Hames via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a>> wrote:</div><br class=""><div class=""><div dir="ltr" class="">Aaaand I'm (mostly) caught up. Phew.<div class=""><br class=""></div><div class="">FWIW Chris B is right: I had been put off commenting on this thread by the length, and the number of git discussions that have come before this. He convinced me to make the effort to put my 2 cents in though - thanks Chris.</div><div class=""><br class=""></div><div class="">So - for my use-case I don't have strong feelings one way or the other<a href="https://www.youtube.com/watch?v=fpaQpyU_QiM" target="_blank" class="">*</a>. That said, something about the discussion so far strikes me as dissonant: If we're going to break out some sub-projects (the test-suite for licensing reasons, the runtimes for modularity) then it's not really a mono-repo any more. It's a multi-repo where we've collapsed some (but not all) of the existing repos. </div></div></div></blockquote><div class=""><br class=""></div></span><div class="">This a narrow view IMO: the criteria #1 Chris mentioned to include projects in the monorepo was " must be tightly coupled to specific versions”. </div><div class="">It means that even with the test suite (and possibly some runtime) out of the monorepo, all the software that is tightly coupled would be in the monorepo, and that alone would be enough to alleviate the needs for (most of the) tooling/infrastructure.</div><span class=""><div class=""><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">To the extent that we have to build tooling to support multiple-repos (auto-mergers for test bots, command line utils for devs who want the main repo plus tests plus ...), could we re-use that to keep the existing modular project setup?</div></div></div></blockquote><div class=""><br class=""></div></span><div class="">I find it a fairly different scale to clone 3 repos on a bot versus having to keep multiple repositories *in sync* (i.e. cross repository synchronization).</div><span class=""><div class=""><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""> This might be a fairly low-benefit proposition if the tools we develop were only usable by in-tree projects, but there are many other users of LLVM (Swift leaps to mind since I'm at Apple, but there are many others) who might appreciate the ability to use LLVM-provided tools to pick-and-mix LLVM projects into their repos. Otherwise, every downstream user will have to roll some version of these tools themselves. </div></div></div></blockquote><div class=""><br class=""></div></span><div class="">Different problems, different tools… I’m against artificially creating “problems" for upstream developers only because the tooling to solve them works for downstream users.</div><div class=""><br class=""></div><div class="">— </div><span class="HOEnZb"><font color="#888888" class=""><div class="">Mehdi</div></font></span><span class=""><div class=""><br class=""></div><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Thu, Jul 28, 2016 at 3:19 PM, Renato Golin via llvm-dev <span dir="ltr" class=""><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 28 July 2016 at 22:12, Chris Bieneman <<a href="mailto:beanz@apple.com" target="_blank" class="">beanz@apple.com</a>> wrote:<br class="">
> It is worth pointing out the Jenkins job that runs that is a playground I setup for myself. It is nowhere near production ready, and it will fail frequently as I iterate messing around with it.<br class="">
<br class="">
</span>Sure, I think that's implied.<br class="">
<div class=""><div class=""><br class="">
cheers,<br class="">
--renato<br class="">
_______________________________________________<br class="">
LLVM Developers mailing list<br class="">
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a><br class="">
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank" class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br class="">
</div></div></blockquote></div><br class=""></div>
_______________________________________________<br class="">LLVM Developers mailing list<br class=""><a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a><br class=""><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank" class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br class=""></div></blockquote></span></div><br class=""></div></blockquote></div><br class=""></div>
</div></blockquote></div><br class=""></body></html>