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

[Renato Golin via llvm-dev]

Hi Eric,

Sorry, my reply was a lot more "formal" than I intended. I was trying to
explain the concerns to a finer level of detail than necessary, while also
trying to reply to some of Tom's concerns. I wasn't successful.

I agree with your points. I think we're all clear that the expected support
is user-based, as I tried to express in the "support policy". Conflicts in
merges and backports are the sole responsibility of the sub-community.

I think we won't have any of the problems we discussed in practice. And if
we do, we'll be able to solve them fairly quickly and painlessly.

So, just to make it clear: I don't mind Bazel in the repository at all,
with the support level as discussed, but it would be nice if Bazel and GN
ended up in the same place.

cheers,
--renato

On Fri, 4 Dec 2020 at 21:41, Eric Christopher <echristo at gmail.com> wrote:

> 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/1d425236/attachment.html>