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

[Stella Laurenzo via llvm-dev]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20201029/a2382b53/attachment.html>