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

[Eric Christopher via llvm-dev]

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.

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/53c4c869/attachment.html>