[llvm-dev] Contributing Bazel BUILD files similar to gn

Fri Oct 30 00:16:09 PDT 2020

Both Eric Astor and Stella have great points here. There's an implicit cost
but as long as we all agree on having it, it's way cheaper than the
alternatives if we consider individual proposals affecting different sub
communities equally (build system, editors, etc).

I use Linux, CMake and vim. My needs are catered. But clearly other
people's needs are not. I see that as a small cost to pay IFF we set a very
clear rule as to what is first tier and what is second, third, etc. And IFF
the other tiers don't negatively impact the first.

In the end, these are the existing rules for code (experimental, temporary,
new stuff), so I see no conflict in extending it to meta support.

I also agree with Eric's point about taking a step back and defining this
policy first, then discussing the inclusion of Bazel will hopefully be
trivial.

Cheers,
Renato

On Fri, 30 Oct 2020, 06:04 Stella Laurenzo via llvm-dev, <
llvm-dev at lists.llvm.org> wrote:

>
>
> On Thu, Oct 29, 2020 at 10:39 PM Neil Nelson via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Some good remarks Stella.
>>
>> What does *second tier* mean?
>>
>
> It was mainly me reaching (probably badly) for a term to sum up what
> others have alluded to:
>
>    - Has some level of community interest in consuming LLVM as a dep from
>    the build setups that use it -- at least enough to commit to maintaining it
>    in reasonably good working order.
>    - Has no expectation of maintenance by those not associated with
>    consuming it.
>    - Is not distributed as part of LLVM releases.
>    - Is not guaranteed to work at arbitrary LLVM commits.
>    - Probably has a Discourse tag under an "Unsupported Build Systems"
>    top-level or something.
>    - Is advertised specifically as an unsupported way to take a dep on
>    LLVM (but if you have problems, feel free to reach out to <insert discourse
>    tag> for ad-hoc help).
>    - Could be deleted at any time (but with notice given to users so they
>    can take a copy with them).
>
>  Practically, I've seen many build systems with some level of interop
> available with respect to their more established peers (i.e. New Build
> System A can source deps from Older Build System B), but often with an
> impedance mismatch that tends to make it suitable for relatively simple
> things and hard to maintain for more complicated. This is actually the case
> with Bazel (and based on the FB feedback, to some extent Buck) -- and can
> be severe enough to cause maintaining a mirror built natively for the build
> system worth it. This seems to impact people using "hermetic" build systems
> the worst because they like to have pure source deps on everything that
> they possibly can, and the usual escape hatches (install and point to
> headers/libs) don't work well for their setups for whatever reason.
>
> I don't think the LLVM Project should have any obligation to keep such
> things running, but providing some hosting and a place to live for what
> amounts to real people trying to use and interact (and often contribute) to
> the project seems like a pretty minimal thing to provide and it helps keep
> the community together, even though some members have chosen to live on
> weird islands and like to declare dependencies on all of their headers :)
>
> There are additional directories in the LLVM download such as flang,
>> compiler-rt, openmp, but these do not seem to be second-tier though there
>> may be a sense in which they are.
>>
>> Is the idea of second-tier that there will be additional directories or
>> programs embedded in the existing LLVM directories not available for use to
>> those without bazel? If that is the case, then what is the relevance of
>> those contributions?
>>
>> It seems we are saying that if a contribution is relevant then either it
>> is in the cmake build, making bazel superfluous to obtain a build, or it is
>> in a bazel-only build. A cmake build would be required for the parts we
>> have now and then an additional bazel build for the second-tier parts.
>>
>> There is talk of gn. I am not seeing gn installed here but am not aware
>> it is required. Is it the case that whatever gn does, cmake does, or is it
>> the case there is a necessary gn build sequence in LLVM somewhere?
>>
>> Neil Nelson
>> On 10/29/20 10:22 PM, Stella Laurenzo via llvm-dev wrote:
>>
>> On to my note...
>>
>> One other cost to consider is that if we have this outside of the
>> monorepo, and outside of the LLVM organization, we have a contribution
>> barrier up which firmly entrenches this as a "Google thing", and I don't
>> think that is a good thing for LLVM as a project... There will be a
>> different committer pool, different policy enforcement (such as accepting
>> Google's CLA), different comms channels, etc. Projects, both OSS and
>> private, outside of Google do use both bazel and LLVM, and it would be
>> best, in my opinion, if they could source and contribute all of the LLVM
>> bits from the LLVM org, including second tier build support, where it
>> exists (and we should clearly cordone this off as some kind of second tier).
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://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/20201030/9444946e/attachment.html>