> On Jan 17, 2017, at 7:24 AM, David Chisnall <David.Chisnall at
cl.cam.ac.uk> wrote:
>
> On 17 Jan 2017, at 01:17, Chris Lattner via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
>>
>> - Monorepo is the “natural” way to use git. Submodules are possible to
use, but add significant complexity.
>
> Having used submodules in a couple of projects, I’ve not found them to
cause more difficulty than they avoided; however, they do have an issue
specifically with GitHub, which is that tarballs don’t include submodules so
packages are slightly harder to construct (they must point to two releases).
Another one is the future possibility of “pull request”, which is annoying to
get across repository.
>
>> - The download size of a mono-repo is manageable, and seems scalable
for a project the size of LLVM (including reasonable growth over the next 10
years).
>
> The download size of a mono-repo is fine for anyone who would be checking
out LLVM today. compiler-rt and libc++ are both useful without any of the rest
of LLVM and contributors to libc++ rarely check out anything more than libc++
(perhaps libc++abi) today.
>
>> - As Medhi says, according to surveys and discussions in forums like
the LLVM Dev Meeting BoF, most people who care are in favor of mono-repo.
>
> From the online surveys, I think the split was roughly 50:50.
I don’t know on what data you’re basis this on. I looked very closely and here
are two questions that contradicts your view.
Question: “If we could go back in time and restart the project with today's
technologies, which repository scheme would be best for the LLVM project?”
-> 55 to 36 in favor of the mono-repo
Question: "Assuming mono-repo gets adopted, how do you plan to contribute?”
-> Only 11% were saying before the BoF that they will continue to use split
repository (through git-svn, as today), 86% will use the mono-repo.
> I’d be very hesitant to regard anything at a BoF as representative of the
wider community, as the set of people who have the time and funding to attend a
conference is quite distinct from the wider community (particularly for the US
DevMeeting, which is right in the middle of university term times). We’ve made
this mistake in FreeBSD before.
I believe it representative enough of the people contributing to LLVM that have
an opinion on the question. It obviously can’t be *all* of them in the same
room, but with over 400 attendees, the conference seems like a valid signal to
me. Especially many of the people that have been very active on this issue were
in the room.
>> - The people most impacted by mono-repo are those who want to build
just compiler-rt. We want these people to be happy, but they are very few in
number, and their benefit needs to be balanced against the benefit for the
larger community that builds llvm (and typically clang or another front end).
>
> I believe that the big win for the monorepo is the ability to bisect
usefully. It’s currently very difficult to bisect clang, because you can’t
bisect clang and llvm independently (LLVM API changes frequently break clang)
and they’re in different git repos (or non-enclosing svn subtrees) and so it
needs some manual intervention. Having them in the same repo would ensure that
they are in sync and make bisecting trivial.
>
> In contrast, there is not (and should not be) tight coupling between LLVM
and libc++, libunwind, libc++abi, and compiler-rt. There *may* be ordering
requirements (e.g. revision X of libc++ requires c++17 features of revision Y of
clang for c++17 features to work), but it is incredibly valuable to bisect these
independently to find whether a particular change is a new compiler bug, a new
library bug, or an old library bug that is triggered by new compiler behaviour
(or an old compiler bug that is triggered by new code).
>
> I would be in favour of a monorepo for everything that links against LLVM
libraries and everything else being in separate repos.
>
>> Overall, it seems clear that either approach could work, but mono seems
to win out because it is more popular and more simple. It would require tweaks
to LLVM’s cmake system though: instead of deciding to build a subproject based
on whether it is checked out, it should instead be based on configuration time
flags.
>
> I believe that most of this works already - you can opt out of building
components that are checked out.
Actually you have to opt-in instead of opt-out right now, and I encourage you to
try it if you’re contributing to LLVM:
http://llvm.org/docs/GettingStarted.html#for-developers-to-work-with-a-git-monorepo
<http://llvm.org/docs/GettingStarted.html#for-developers-to-work-with-a-git-monorepo>
—
Mehdi
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170117/fcf9fac0/attachment.html>