[llvm-dev] RFC: Contributing Bazel BUILD files in the "peripheral" support tier

[Eric Christopher via llvm-dev]

Hi Renato,

As a summary: At its core I think that this is a "lowering the barrier to
entry" for llvm rather than a support issue. No one is suggesting that this
is supported other than by its users inside an easily removed directory
similar to how a lot of specific support has been handled.

Your questions are seeming to move the bar far past what anyone is asking
for and so it seems that there's a disconnect occurring here. I'll answer a
few of your concerns inline.


> Tom is worried on a meta level, both as cementing the precedent (GN was a
> trial, BAZEL makes it official) and as complicating the merge process. I
> agree with him 100%.
>
>
Makes what official? I think the "support" story - "there is none" - is
pretty clear here. As far as merging it's pretty clear this is a "user
supported" rather than "community supported" process. No one, including me,
wants to add another supported llvm build system. And let's be honest, most
people didn't even notice that gn was added until it was pointed out and it
hasn't caused any issues. There's no assumption of anything working
anywhere.


> It's already complicated to make sure backports on various projects don't
> break other projects (especially in the core LLVM), and by adding build
> systems to the mix, we'd be adding a new dimension in the problem space.
>
> I am more worried about following different paths for different build
> systems (non-overlapping features) and encouraging people to build with an
> "alternative" build system because CMake yet doesn't support something that
> they do.
>
> I really don't want to get to a point where each system has a set of
> unique features, in which case, we'll have three "official" build systems.
> I know this isn't what you're proposing, but it's a likely outcome once we
> "support" (core or peripheral) more than one.
>
> We have had that before with autoconf, as I mentioned.
>
>
There's no notion of having official build systems here and as the previous
build system maintainer and owner of autoconf I'm pretty sure this doesn't
reflect how the situation was. The dual aspect of cmake and autoconf was an
explicit acknowledgment that we wanted to support both in tree while we
moved from one to the other. In addition, we still have the vestiges of
some other build systems in tree and tools used exclusively for outside
projects for simplicity.


> I can really only speak for Google projects. I have also noticed several
>> other Bazel build configurations in the wild, e.g. PlaidML
>> <https://github.com/plaidml/plaidml/blob/master/vendor/llvm/llvm.BUILD> (Intel)
>> or this bazel_llvm <https://github.com/ChrisCummins/bazel_llvm> project
>> that I found after someone contributed a doc fix. I believe in the last
>> thread someone from Facebook mentioned that Bazel build files would also be
>> relatively easily translatable to their internal Bazel-derived build
>> system, Buck. Someone from Lyft also expressed interest in using a Bazel
>> build configuration if it was in-tree. But I can't really speak to the
>> motivations, road maps, etc. for any of these people, companies, or
>> projects (if you're reading, please chime in ;-P).
>>
>
> The purpose of this question was to understand how many new projects will
> want to move inside the LLVM umbrella (core, peripheral, incubator) that
> can only be built with BAZEL.
>
>
This is a different question and one I don't think we need to address,
however, if it helps...

As you say here:


> If we accept GN/BAZEL as a supported build system, we should still require
> new projects to build with CMake, in addition to their native ones, if
> different.
>
>
I would be against any project that does not build with CMake being added
to the llvm project. If they want to add support (or even support another
build system) to one of the optional, and unsupported, build systems then
that's up to them or the people that care about those build systems. Same
with editor integrations :)


> This could still "leave out" some features in the native build system (if
> supported) that haven't been moved to CMake, and that's how you get
> disjoint support levels I mentioned above.
>
>
As I said in my intro - at its core this isn't a support issue. Adding in
the capability of something being able to build with different build
systems helps the llvm project both be open to new contributors and
integrations. We don't need to support them more than the people care to
work on it, but having the capability means that people whose primary goal
is integrating llvm into various projects can have those projects' build
systems live alongside our supported meta-build system. This is basically
"tooling" in a directory that makes integrating with projects that depend
upon llvm easier and lowers the barrier for people that work on those
projects to more easily work with llvm.

I hope this helps and would be happy to continue the discussion with you
either here, offline, or via video conference.

Thanks!

-eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20201204/16ab5ee8/attachment.html>