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

Fri Dec 4 15:47:00 PST 2020

On Fri, Dec 4, 2020 at 3:26 PM Eric Christopher <echristo at gmail.com> wrote:

> Hi Renato,
>
> On Fri, Dec 4, 2020 at 6:07 PM Renato Golin <rengolin at gmail.com> wrote:
>
>> 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.
>>
>>
> Awesome. I'm glad to get that cleared up. I was definitely surprised by
> your response :)
>
>
>> 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.
>>
>>
> Sweet, thanks. +Tom Stellard <tstellar at redhat.com>  any further thoughts
> here?
>
>
>> 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.
>>
>>
> I see it as a parallel directory in the same place. I'd very much prefer
> not to add build systems that require sprinkling files all over the source
> base.
>
> Agreed. And I don't care too much where that place is. I was only
proposing `utils/` at the root based on some feedback complaining about
mailing-list traffic and offering to propose a move of `llvm/utils/gn` to
`utils/gn` as a prerequisite if that was preferred. Obviously it's easier
for me to put it alongside gn in `llvm/utils/bazel`, but I thought since we
were discussing this it might be a good time to consider whether that's
actually the best place :-) And at some point I also mentioned that having
"unsupported" somewhere in the path might help make the support status
extremely clear, e.g. `utils/unsupported/[bazel|gn]`

Thanks!
>
> -eric
>
>
>> 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/1eb2d5b1/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3992 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20201204/1eb2d5b1/attachment.bin>