llvm dev - May 2017 - Add more projects into Git monorepo

Is this intended to be the monorepo that eventually becomes the official repo,
because if so I strongly object to putting libunwind, libc++ and libc++abi in
it.  I have recently been working on bring-up for libc++ and libunwind on a new
platform and the integration of libunwind with the LLVM build system is already
annoying (you can’t build it unless you have a working C++ standard library
implementation for your target, even thought it’s a dependency for libc++),
having to have a complete LLVM checkout would be even more overhead.

David
> On 7 May 2017, at 08:07, NAKAMURA Takumi via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> I have done just now. 5 repos added including debuginfo-tests.
> ATM, it includes 17 repos total.
> 
> - Created the new repo;
https://github.com/llvm-project/llvm-project-20170507.git
>   Branches will come later.
> - The previous repository has a merge commit that includes new repo. It
will stick to r302363.
> - Submodule repo has been pushed with -f.
> 
> Rebasing to new branch(es) will take a few minutes. Please be patient.
> 
> Thanks, Takumi
> 
> On Mon, May 1, 2017 at 11:27 PM NAKAMURA Takumi <geek4civic at
gmail.com> wrote:
> I am planing to add projects into
https://github.com/llvm-project/llvm-project in near future, possibly this week.
> 
> Before doing that, I would like to ask users of it.
> 1st option is my preference in each paragraph. Let me know if you have
other suggestions.
> 
> * What is added?
>   I will add; libunwind, llgo, openmp and parallel-libs.
>   May I also add debuginfo-tests?
> 
> * Will inactive projects be dropped?
>   I won't do.
> 
> * Where shall I push the new monorepo?
>   - Create a new repository, like llvm-project-201705XX, or *-(number of
repos)
>   - Push new branches into the current llvm-project.git as different branch
name, like master-201705XX.
>   - Force overwrite llvm-project.git/master. I won't do since I was
blamed when I tried in the last time.
> 
> * When I migrate trunk to the new one, how the previous branches will be?
>   - Push a merge-commit to the new one. Its commit message will announce
the new repo.
>   - Leave.
>   - Update also previous branches as well. (I don't want to do)
> 
> * What should be done regarding to
https://github.com/llvm-project/llvm-project-submodule ?
>   For consistency, I could create a new repo.
>   But I think I can overwrite branches, since I assume this is read-only.
> 
> Thanks, Takumi
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

Hi all,

I don't hope so, I haven't seen any public poll by the LLVM Foundation
about which projects to include (might have missed that though).

I'm also opposed to having openmp and parallel-libs in there as it adds
unnecessary overhead to everyone just interested in the OpenMP runtime. On the
poll to the git migration in general, there was some mention on "only
include repositories that are version-locked", ie LLVM libs, Clang,
compiler-rt and possibly lld (?).

Cheers,
Jonas

-----Original Message-----
From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of David
Chisnall via llvm-dev
Sent: Sunday, May 7, 2017 10:01 AM
To: NAKAMURA Takumi <geek4civic at gmail.com>
Cc: llvm-dev <llvm-dev at lists.llvm.org>
Subject: Re: [llvm-dev] Add more projects into Git monorepo

Is this intended to be the monorepo that eventually becomes the official repo,
because if so I strongly object to putting libunwind, libc++ and libc++abi in
it.  I have recently been working on bring-up for libc++ and libunwind on a new
platform and the integration of libunwind with the LLVM build system is already
annoying (you can’t build it unless you have a working C++ standard library
implementation for your target, even thought it’s a dependency for libc++),
having to have a complete LLVM checkout would be even more overhead.

David
> On 7 May 2017, at 08:07, NAKAMURA Takumi via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> I have done just now. 5 repos added including debuginfo-tests.
> ATM, it includes 17 repos total.
> 
> - Created the new repo;
https://github.com/llvm-project/llvm-project-20170507.git
>   Branches will come later.
> - The previous repository has a merge commit that includes new repo. It
will stick to r302363.
> - Submodule repo has been pushed with -f.
> 
> Rebasing to new branch(es) will take a few minutes. Please be patient.
> 
> Thanks, Takumi
> 
> On Mon, May 1, 2017 at 11:27 PM NAKAMURA Takumi <geek4civic at
gmail.com> wrote:
> I am planing to add projects into
https://github.com/llvm-project/llvm-project in near future, possibly this week.
> 
> Before doing that, I would like to ask users of it.
> 1st option is my preference in each paragraph. Let me know if you have
other suggestions.
> 
> * What is added?
>   I will add; libunwind, llgo, openmp and parallel-libs.
>   May I also add debuginfo-tests?
> 
> * Will inactive projects be dropped?
>   I won't do.
> 
> * Where shall I push the new monorepo?
>   - Create a new repository, like llvm-project-201705XX, or *-(number of
repos)
>   - Push new branches into the current llvm-project.git as different branch
name, like master-201705XX.
>   - Force overwrite llvm-project.git/master. I won't do since I was
blamed when I tried in the last time.
> 
> * When I migrate trunk to the new one, how the previous branches will be?
>   - Push a merge-commit to the new one. Its commit message will announce
the new repo.
>   - Leave.
>   - Update also previous branches as well. (I don't want to do)
> 
> * What should be done regarding to
https://github.com/llvm-project/llvm-project-submodule ?
>   For consistency, I could create a new repo.
>   But I think I can overwrite branches, since I assume this is read-only.
> 
> Thanks, Takumi
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5792 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170508/e7f65c50/attachment.bin>

Just to be sure:

https://github.com/llvm-project <https://github.com/llvm-project>

is different from

https://github.com/llvm <https://github.com/llvm>

isn't it?

The migration of the reference/official llvm repository would be towards the
latter I presume?

- Matthias
> On May 7, 2017, at 11:33 PM, Hahnfeld, Jonas via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> Hi all,
> 
> I don't hope so, I haven't seen any public poll by the LLVM
Foundation about which projects to include (might have missed that though).
> 
> I'm also opposed to having openmp and parallel-libs in there as it adds
unnecessary overhead to everyone just interested in the OpenMP runtime. On the
poll to the git migration in general, there was some mention on "only
include repositories that are version-locked", ie LLVM libs, Clang,
compiler-rt and possibly lld (?).
> 
> Cheers,
> Jonas
> 
> -----Original Message-----
> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of
David Chisnall via llvm-dev
> Sent: Sunday, May 7, 2017 10:01 AM
> To: NAKAMURA Takumi <geek4civic at gmail.com>
> Cc: llvm-dev <llvm-dev at lists.llvm.org>
> Subject: Re: [llvm-dev] Add more projects into Git monorepo
> 
> Is this intended to be the monorepo that eventually becomes the official
repo, because if so I strongly object to putting libunwind, libc++ and libc++abi
in it.  I have recently been working on bring-up for libc++ and libunwind on a
new platform and the integration of libunwind with the LLVM build system is
already annoying (you can’t build it unless you have a working C++ standard
library implementation for your target, even thought it’s a dependency for
libc++), having to have a complete LLVM checkout would be even more overhead.
> 
> David
> 
>> On 7 May 2017, at 08:07, NAKAMURA Takumi via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
>> 
>> I have done just now. 5 repos added including debuginfo-tests.
>> ATM, it includes 17 repos total.
>> 
>> - Created the new repo;
https://github.com/llvm-project/llvm-project-20170507.git
>>  Branches will come later.
>> - The previous repository has a merge commit that includes new repo. It
will stick to r302363.
>> - Submodule repo has been pushed with -f.
>> 
>> Rebasing to new branch(es) will take a few minutes. Please be patient.
>> 
>> Thanks, Takumi
>> 
>> On Mon, May 1, 2017 at 11:27 PM NAKAMURA Takumi <geek4civic at
gmail.com> wrote:
>> I am planing to add projects into
https://github.com/llvm-project/llvm-project in near future, possibly this week.
>> 
>> Before doing that, I would like to ask users of it.
>> 1st option is my preference in each paragraph. Let me know if you have
other suggestions.
>> 
>> * What is added?
>>  I will add; libunwind, llgo, openmp and parallel-libs.
>>  May I also add debuginfo-tests?
>> 
>> * Will inactive projects be dropped?
>>  I won't do.
>> 
>> * Where shall I push the new monorepo?
>>  - Create a new repository, like llvm-project-201705XX, or *-(number of
repos)
>>  - Push new branches into the current llvm-project.git as different
branch name, like master-201705XX.
>>  - Force overwrite llvm-project.git/master. I won't do since I was
blamed when I tried in the last time.
>> 
>> * When I migrate trunk to the new one, how the previous branches will
be?
>>  - Push a merge-commit to the new one. Its commit message will announce
the new repo.
>>  - Leave.
>>  - Update also previous branches as well. (I don't want to do)
>> 
>> * What should be done regarding to
https://github.com/llvm-project/llvm-project-submodule ?
>>  For consistency, I could create a new repo.
>>  But I think I can overwrite branches, since I assume this is
read-only.
>> 
>> Thanks, Takumi
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170508/38b1250e/attachment-0001.html>

2017-05-07 1:01 GMT-07:00 David Chisnall via llvm-dev <
llvm-dev at lists.llvm.org>:
> Is this intended to be the monorepo that eventually becomes the official
> repo, because if so I strongly object to putting libunwind, libc++ and
> libc++abi in it.  I have recently been working on bring-up for libc++ and
> libunwind on a new platform and the integration of libunwind with the LLVM
> build system is already annoying (you can’t build it unless you have a
> working C++ standard library implementation for your target, even thought
> it’s a dependency for libc++), having to have a complete LLVM checkout
> would be even more overhead.
>
Please clarify the overhead.

-- 
Mehdi



>
> David
>
> > On 7 May 2017, at 08:07, NAKAMURA Takumi via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
> >
> > I have done just now. 5 repos added including debuginfo-tests.
> > ATM, it includes 17 repos total.
> >
> > - Created the new repo; https://github.com/llvm-
> project/llvm-project-20170507.git
> >   Branches will come later.
> > - The previous repository has a merge commit that includes new repo.
It
> will stick to r302363.
> > - Submodule repo has been pushed with -f.
> >
> > Rebasing to new branch(es) will take a few minutes. Please be patient.
> >
> > Thanks, Takumi
> >
> > On Mon, May 1, 2017 at 11:27 PM NAKAMURA Takumi <geek4civic at
gmail.com>
> wrote:
> > I am planing to add projects into https://github.com/llvm-
> project/llvm-project in near future, possibly this week.
> >
> > Before doing that, I would like to ask users of it.
> > 1st option is my preference in each paragraph. Let me know if you have
> other suggestions.
> >
> > * What is added?
> >   I will add; libunwind, llgo, openmp and parallel-libs.
> >   May I also add debuginfo-tests?
> >
> > * Will inactive projects be dropped?
> >   I won't do.
> >
> > * Where shall I push the new monorepo?
> >   - Create a new repository, like llvm-project-201705XX, or *-(number
of
> repos)
> >   - Push new branches into the current llvm-project.git as different
> branch name, like master-201705XX.
> >   - Force overwrite llvm-project.git/master. I won't do since I
was
> blamed when I tried in the last time.
> >
> > * When I migrate trunk to the new one, how the previous branches will
be?
> >   - Push a merge-commit to the new one. Its commit message will
announce
> the new repo.
> >   - Leave.
> >   - Update also previous branches as well. (I don't want to do)
> >
> > * What should be done regarding to https://github.com/llvm-
> project/llvm-project-submodule ?
> >   For consistency, I could create a new repo.
> >   But I think I can overwrite branches, since I assume this is
read-only.
> >
> > Thanks, Takumi
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170508/04dc1cad/attachment.html>

On 8 May 2017, at 20:51, Mehdi AMINI <joker.eph at gmail.com>
wrote:
> 
> 
> 2017-05-07 1:01 GMT-07:00 David Chisnall via llvm-dev <llvm-dev at
lists.llvm.org>:
> Is this intended to be the monorepo that eventually becomes the official
repo, because if so I strongly object to putting libunwind, libc++ and libc++abi
in it.  I have recently been working on bring-up for libc++ and libunwind on a
new platform and the integration of libunwind with the LLVM build system is
already annoying (you can’t build it unless you have a working C++ standard
library implementation for your target, even thought it’s a dependency for
libc++), having to have a complete LLVM checkout would be even more overhead.
> 
> Please clarify the overhead.
My clone of libunwind is around 4MB.  A clone of LLVM is 2-3 orders of magnitude
bigger.  The clone on my local system doesn’t matter too much (though it would
be an annoying waste), because I have spare disk space, but each project, once
it’s working, also gets cloned to our CI system, which is always short on disk
space because it archives build artefacts.  Network bandwidth is also an issue.

There’s also the secondary issue that it is valuable to be able to build these
components out of tree, yet this is currently fragile and is likely to be broken
even more if we’re insisting on the monorepo.

We are currently able to target our platform from LLVM (as a cross-compiler),
but not build LLVM to run on it, so it is unhelpful to have stuff that we
compile for x86 and stuff that we compile for our target in the same repo,
because we aggregate the stuff that we build for the target (libunwind, libc++,
and so on) when we build images.

Finally, there’s the philosophical / software engineering issue.  There should
be no tight coupling between libunwind and anything else in the LLVM tree. 
Libunwind implements a set of well-documented and stable APIs.  These are used
by other components, but are equally useful in other contexts (i.e. any compiler
for any language that uses the Itanium unwind model).  From the perspective of
someone hacking on libunwind, LLVM is an unrelated project (though one that
shares coding conventions - an analogy would be two projects under the Apache
umbrella) and there is absolutely no reason to insist that libunwind developers
should clone a massive unrelated project to work on the code that they want to
work on.

All of this applies to libc++ and libc++abi as well.

David