Eric Christopher via llvm-dev
2020-Dec-04 23:26 UTC
[llvm-dev] RFC: Contributing Bazel BUILD files in the "peripheral" support tier
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>
Geoffrey Martin-Noble via llvm-dev
2020-Dec-04 23:47 UTC
[llvm-dev] RFC: Contributing Bazel BUILD files in the "peripheral" support tier
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 onlyproposing `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>