[llvm-dev] Add more projects into Git monorepo

[Mehdi AMINI via llvm-dev]

2017-05-09 8:17 GMT-07:00 David Chisnall <David.Chisnall at cl.cam.ac.uk>:

> On 9 May 2017, at 15:58, Mehdi AMINI <joker.eph at gmail.com> wrote:
>
> > I'd expect any CI system to be able to cache this.
> > Also if you're issue is archiving a lot of build artifacts, the constant
> cost of the checkout isn't gonna matter that much.
> > Finally, the read-only individual repo can still be used by CI, which
> address this entirely.
>
> If we want to pull in new libunwind fixes from upstream, we’ll also pull
> in irrelevant LLVM, clang, lldb, lld, and so on changes.  This translates
> to extra bandwidth and storage requirements for *every* copy of the
> libunwind repo that we need.
>

I'm not sure if you really read the last sentence of what I wrote, or if
you followed the previous discussions on the plan here?
At this point I believe that this concern is non-existent per the read-only
individual repo.


>
> If we follow the monorepo approach downstream and merge these independent
> repos, then we add extra merges for everyone downstream because people
> committing improvements to our LLVM and clang trees will require rebase
> pulls for anyone working on libc++ or libunwind, even though the changes
> were to a component that they’re not needing to build, let alone modify.
>

Every downstream has its own choice, I'm not sure what's the point here? If
it is not relevant to you, then don't do it...


>
> > There is another philosophical perspective: encouraging communities to
> get closer together. You talking about "libunwind developers", and there
> are "lldb developers" as well, I rather get closer to: "we're working on
> the same project", with shared practices and goals. And ultimately, to come
> back to your software engineering practices, encouraging code motion and
> code reuse between sub-projects.
>
> I disagree,  [...].
>

We can leave it there :)
There have been extensive discussions, a BoF, and documentations, please
refer you to these first (granted we haven't really talked about libunwind,
but I'm not sure many people will be strongly opposed to libunwind having
its separate life).


>
> >> All of this applies to libc++ and libc++abi as well.
> >
> > Ultimately I don't know about libunwind, and if it has to live
> separately it is not a big deal. The others (libc++ and libc++abi for
> instance) are more tied to the rest of the project though.
> > We duplicate the demangler from libc++abi in llvm for instance, and this
> is quite an important software engineer issue to me.
>
> The requirements for a libc++abi demangler and a generic LLVM one are very
> different.
>


They are so different that we ask anyone who want to change something to
the LLVM demangler to make the change in compiler-rt first and then pull
the patch...
Maintaining two demanglers (or more) is silly IMO (no-one is even
maintaining the existing one...).

-- 
Mehdi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170509/0f6fb7f9/attachment.html>