llvm dev - Dec 2020 - RFC: Contributing Bazel BUILD files in the "peripheral" support tier

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>

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>