Proposal for adding Bazel build configuration in-tree with peripheral support

[GMNGeoffrey]

Summary

This is a draft proposal to be discussed in a [PITCH] thread on llvm-dev
https://groups.google.com/g/llvm-dev/c/bU5Lg2sB6es

[GMNGeoffrey]

• Add links to pitch thread now that it exists

[ctetreau]

Question: Would there be an expectation that unsupported build systems are in a good state for LLVM version branches? If I checkout the git tag for a final LLVM release, should I be able to expect that the build system is functional at that commit?

proposals/LP0002-UnsupportedBuildConfigurations.md

55 ↗

(On Diff #315936)

Typo?

[tstellar]

If this pitch is accepted, then what are the next steps required in order for bazel or another build system to be added to tree? For example, can they automatically be added if they meet the support policy requirements or does there need to be some kind of community ack for? I think the pitch needs to be more clear about what this process is.

[rriddle]

proposals/LP0002-UnsupportedBuildConfigurations.md

72 ↗

(On Diff #315936)

121 ↗

(On Diff #315936)

140 ↗

(On Diff #315936)

[beanz]

All of my major concerns about adding additional build systems are addressed by the support policy and classifying additional build systems as “peripheral”.

To summarize, my main concern in the past was that supporting more than one primary build system back when we had CMake and autoconf placed significant maintenance burden on the community. By classifying additional build systems as “peripheral” we clearly denote that their maintenance is not spread outside the users of the system, which should avoid the problems we had in the past.

Generally speaking this proposal looks good to me.

[rengolin]

In D94451#2491668, @tstellar wrote:

If this pitch is accepted, then what are the next steps required in order for bazel or another build system to be added to tree? For example, can they automatically be added if they meet the support policy requirements or does there need to be some kind of community ack for? I think the pitch needs to be more clear about what this process is.

This is addressed by https://llvm.org/docs/SupportPolicy.html#inclusion-policy

[GMNGeoffrey]

In D94451#2491553, @ctetreau wrote:

Question: Would there be an expectation that unsupported build systems are in a good state for LLVM version branches? If I checkout the git tag for a final LLVM release, should I be able to expect that the build system is functional at that commit?

No. I think there should be no expectation. If the community members who care about the component can figure out a way to make this happen that doesn't make releasing harder for the release manager then they could try to arrange this, but I suspect that's not really possible. I think if that needs to be clearer, it should be clarified in the support policy. https://llvm.org/docs/SupportPolicy.html#peripheral-tier mentions things that aren't "regularly released", but I think that zero expectation of support in releases could be made clearer. Assuming that's already the status quo, I could send it as a patch to the support policy separate from this proposal. Or I could include in this proposal that we'll amend the support policy to reflect that.

In D94451#2495535, @rengolin wrote:

In D94451#2491668, @tstellar wrote:

If this pitch is accepted, then what are the next steps required in order for bazel or another build system to be added to tree? For example, can they automatically be added if they meet the support policy requirements or does there need to be some kind of community ack for? I think the pitch needs to be more clear about what this process is.

This is addressed by https://llvm.org/docs/SupportPolicy.html#inclusion-policy

Yes I'm trying not to duplicate information already in the support policy, where possible.

[GMNGeoffrey]

• Fix typos

[GMNGeoffrey]

proposals/LP0002-UnsupportedBuildConfigurations.md

140 ↗

(On Diff #315936)

I really suck at spelling unsupported, huh?

[tschuett]

The main supporting point for me is that it is peripheral and helps external users of LLVM,, like e.g. Tensorflow. I believe it is a completely different usage scenario than gn or cmake.

[tstellar]

In D94451#2496129, @GMNGeoffrey wrote:

In D94451#2491553, @ctetreau wrote:

Question: Would there be an expectation that unsupported build systems are in a good state for LLVM version branches? If I checkout the git tag for a final LLVM release, should I be able to expect that the build system is functional at that commit?

No. I think there should be no expectation. If the community members who care about the component can figure out a way to make this happen that doesn't make releasing harder for the release manager then they could try to arrange this, but I suspect that's not really possible. I think if that needs to be clearer, it should be clarified in the support policy. https://llvm.org/docs/SupportPolicy.html#peripheral-tier mentions things that aren't "regularly released", but I think that zero expectation of support in releases could be made clearer. Assuming that's already the status quo, I could send it as a patch to the support policy separate from this proposal. Or I could include in this proposal that we'll amend the support policy to reflect that.

In D94451#2495535, @rengolin wrote:

In D94451#2491668, @tstellar wrote:

If this pitch is accepted, then what are the next steps required in order for bazel or another build system to be added to tree? For example, can they automatically be added if they meet the support policy requirements or does there need to be some kind of community ack for? I think the pitch needs to be more clear about what this process is.

This is addressed by https://llvm.org/docs/SupportPolicy.html#inclusion-policy

Yes I'm trying not to duplicate information already in the support policy, where possible.

OK, I think it would be better if this pitch was about adding bazel specifically. I don't really see what having a generic "unsupported build system" pitch gains us, when the specific build systems will all still need to go through the RFC process.

[ctetreau]

In D94451#2496129, @GMNGeoffrey wrote:

In D94451#2491553, @ctetreau wrote:

Question: Would there be an expectation that unsupported build systems are in a good state for LLVM version branches? If I checkout the git tag for a final LLVM release, should I be able to expect that the build system is functional at that commit?

No. I think there should be no expectation. If the community members who care about the component can figure out a way to make this happen that doesn't make releasing harder for the release manager then they could try to arrange this, but I suspect that's not really possible. I think if that needs to be clearer, it should be clarified in the support policy. https://llvm.org/docs/SupportPolicy.html#peripheral-tier mentions things that aren't "regularly released", but I think that zero expectation of support in releases could be made clearer. Assuming that's already the status quo, I could send it as a patch to the support policy separate from this proposal. Or I could include in this proposal that we'll amend the support policy to reflect that.

The reason I bring this up is that I see two main ways a project would use the LLVM repo: 1) by attempting to keep up with the tip of main, 2) and by basing their project on some fixed git hash. For 2), it would be very nice if someone wants to use LLVM, and wants to build it with Bazel could checkout the tag for LLVM 14 and have a high likelihood of being able to build. Obviously, people attempting to keep up with the tip of main should expect breakages.

I agree that not burdening the release managers is a top goal; they have enough problems. Perhaps the expectation should be that the subcommunity proactively stabilizes their build system during the release candidate period and shepherds any patches required. After the branch, the readme can be updated to spell out how to get a functional build system starting from some release tag. ("checkout llvm 27" or "checkout llvm 27, then cherry pick [hash]")

[GMNGeoffrey]

In D94451#2496546, @tstellar wrote:

In D94451#2496129, @GMNGeoffrey wrote:

In D94451#2491553, @ctetreau wrote:

Question: Would there be an expectation that unsupported build systems are in a good state for LLVM version branches? If I checkout the git tag for a final LLVM release, should I be able to expect that the build system is functional at that commit?

No. I think there should be no expectation. If the community members who care about the component can figure out a way to make this happen that doesn't make releasing harder for the release manager then they could try to arrange this, but I suspect that's not really possible. I think if that needs to be clearer, it should be clarified in the support policy. https://llvm.org/docs/SupportPolicy.html#peripheral-tier mentions things that aren't "regularly released", but I think that zero expectation of support in releases could be made clearer. Assuming that's already the status quo, I could send it as a patch to the support policy separate from this proposal. Or I could include in this proposal that we'll amend the support policy to reflect that.

In D94451#2495535, @rengolin wrote:

In D94451#2491668, @tstellar wrote:

If this pitch is accepted, then what are the next steps required in order for bazel or another build system to be added to tree? For example, can they automatically be added if they meet the support policy requirements or does there need to be some kind of community ack for? I think the pitch needs to be more clear about what this process is.

This is addressed by https://llvm.org/docs/SupportPolicy.html#inclusion-policy

Yes I'm trying not to duplicate information already in the support policy, where possible.

OK, I think it would be better if this pitch was about adding bazel specifically. I don't really see what having a generic "unsupported build system" pitch gains us, when the specific build systems will all still need to go through the RFC process.

So I must confess that I'm a bit frustrated by this comment, Tom. The reason I'm writing this as a pitch is because the RFC(s) I wrote were determined to be "controversial" even after we had a support policy that explicitly discussed build systems. As far as I can tell, none of the objections raised that made it controversial had to do with Bazel in particular or whether its addition could satisfy the requirements of the support policy, but rather had to do with adding unsupported build systems in general. That was surprising to me, since we'd just had a separate RFC for a support policy, which seems like it would have been the ideal time to raise such objections, but people made the reasonable argument that the writing of that policy was very new (although the policies it recorded were not) and the inclusion of build configurations might reasonably have been missed when people were reviewing it. The prevailing view on the thread seemed to be we should escalate the point about unsupported build systems to come to a decision. So in my mind, this pitch is to make explicit and allow further discussion on the inclusion of unsupported build systems in the support policy, whereas before it was just a sentence that mentioned them as an example. I'm sympathetic to that and don't want to be just slipping things through, but I'd also like to actually make progress here and I feel like we have entered exactly the situation you've described as being opposed to when requesting that we escalate to a pitch: that is a "battle of attrition". I think you've raised reasonable concerns about build system proliferation, and I think we should discuss them, but I'm not sure how me writing yet another iteration of this proposal actually helps us here.

I guess I'm fine making this proposal "Unsupported build systems are allowed and Bazel is, in particular", so we don't have to then do yet another RFC, but my plan was to just reopen the previous RFC and return to the issues of Bazel in particular (and even more specifically our implementation of the LLVM config for it, which I think there were some reasonable criticisms of). I'm worried that discussing the specific case means that if some poor soul wants to add, say, a Meson build or whatever they will have to relitigate these points that have already been decided.

Can you understand where I'm coming from here?

[tstellar]

In D94451#2502765, @GMNGeoffrey wrote:

In D94451#2496546, @tstellar wrote:

In D94451#2496129, @GMNGeoffrey wrote:

In D94451#2491553, @ctetreau wrote:

Question: Would there be an expectation that unsupported build systems are in a good state for LLVM version branches? If I checkout the git tag for a final LLVM release, should I be able to expect that the build system is functional at that commit?

No. I think there should be no expectation. If the community members who care about the component can figure out a way to make this happen that doesn't make releasing harder for the release manager then they could try to arrange this, but I suspect that's not really possible. I think if that needs to be clearer, it should be clarified in the support policy. https://llvm.org/docs/SupportPolicy.html#peripheral-tier mentions things that aren't "regularly released", but I think that zero expectation of support in releases could be made clearer. Assuming that's already the status quo, I could send it as a patch to the support policy separate from this proposal. Or I could include in this proposal that we'll amend the support policy to reflect that.

In D94451#2495535, @rengolin wrote:

In D94451#2491668, @tstellar wrote:

If this pitch is accepted, then what are the next steps required in order for bazel or another build system to be added to tree? For example, can they automatically be added if they meet the support policy requirements or does there need to be some kind of community ack for? I think the pitch needs to be more clear about what this process is.

This is addressed by https://llvm.org/docs/SupportPolicy.html#inclusion-policy

Yes I'm trying not to duplicate information already in the support policy, where possible.

OK, I think it would be better if this pitch was about adding bazel specifically. I don't really see what having a generic "unsupported build system" pitch gains us, when the specific build systems will all still need to go through the RFC process.

So I must confess that I'm a bit frustrated by this comment, Tom. The reason I'm writing this as a pitch is because the RFC(s) I wrote were determined to be "controversial" even after we had a support policy that explicitly discussed build systems. As far as I can tell, none of the objections raised that made it controversial had to do with Bazel in particular or whether its addition could satisfy the requirements of the support policy, but rather had to do with adding unsupported build systems in general. That was surprising to me, since we'd just had a separate RFC for a support policy, which seems like it would have been the ideal time to raise such objections, but people made the reasonable argument that the writing of that policy was very new (although the policies it recorded were not) and the inclusion of build configurations might reasonably have been missed when people were reviewing it. The prevailing view on the thread seemed to be we should escalate the point about unsupported build systems to come to a decision. So in my mind, this pitch is to make explicit and allow further discussion on the inclusion of unsupported build systems in the support policy, whereas before it was just a sentence that mentioned them as an example. I'm sympathetic to that and don't want to be just slipping things through, but I'd also like to actually make progress here and I feel like we have entered exactly the situation you've described as being opposed to when requesting that we escalate to a pitch: that is a "battle of attrition". I think you've raised reasonable concerns about build system proliferation, and I think we should discuss them, but I'm not sure how me writing yet another iteration of this proposal actually helps us here.

I guess I'm fine making this proposal "Unsupported build systems are allowed and Bazel is, in particular", so we don't have to then do yet another RFC, but my plan was to just reopen the previous RFC and return to the issues of Bazel in particular (and even more specifically our implementation of the LLVM config for it, which I think there were some reasonable criticisms of). I'm worried that discussing the specific case means that if some poor soul wants to add, say, a Meson build or whatever they will have to relitigate these points that have already been decided.

Can you understand where I'm coming from here?

Yes, and I think there may be some misunderstanding here, because the main reason I suggested you include Bazel in this pitch was to try to save your time and energy.

When I first suggested doing a pitch, my assumption was that the RFC for Bazel would turn into a pitch for Bazel and that would be it, however if we proceed with this pitch as written, then we would have had 2 RFCs, 1 Pitch, and still no final decision about Bazel. This seems to me like much more work then what we need to do, not to mention the fact that it is very confusing, and I don't think it's really fair to expect people who object to the original RFC to keep objecting to all these new proposals.

As I wrote before, I don't really see what a pitch like this would give us. I mean there are negatives to adding Bazel that would be negatives of adding any build systems, so if this pitch is approved, does that mean we aren't allowed to consider these 'generic' negatives when evaluating Bazel?

I don't want this to be any more complicated than it has to be, and to me the ideal pitch would be: 1) Here are the criteria for adding an unsupported build system and 2) Here is why bazel meets this criteria. I believe you already have most of 1, so just add in 2, and then this can be the final discussion about Bazel.

[GMNGeoffrey]

In D94451#2502917, @tstellar wrote:

In D94451#2502765, @GMNGeoffrey wrote:

In D94451#2496546, @tstellar wrote:

In D94451#2496129, @GMNGeoffrey wrote:

In D94451#2491553, @ctetreau wrote:

Question: Would there be an expectation that unsupported build systems are in a good state for LLVM version branches? If I checkout the git tag for a final LLVM release, should I be able to expect that the build system is functional at that commit?

No. I think there should be no expectation. If the community members who care about the component can figure out a way to make this happen that doesn't make releasing harder for the release manager then they could try to arrange this, but I suspect that's not really possible. I think if that needs to be clearer, it should be clarified in the support policy. https://llvm.org/docs/SupportPolicy.html#peripheral-tier mentions things that aren't "regularly released", but I think that zero expectation of support in releases could be made clearer. Assuming that's already the status quo, I could send it as a patch to the support policy separate from this proposal. Or I could include in this proposal that we'll amend the support policy to reflect that.

In D94451#2495535, @rengolin wrote:

In D94451#2491668, @tstellar wrote:

If this pitch is accepted, then what are the next steps required in order for bazel or another build system to be added to tree? For example, can they automatically be added if they meet the support policy requirements or does there need to be some kind of community ack for? I think the pitch needs to be more clear about what this process is.

This is addressed by https://llvm.org/docs/SupportPolicy.html#inclusion-policy

Yes I'm trying not to duplicate information already in the support policy, where possible.

OK, I think it would be better if this pitch was about adding bazel specifically. I don't really see what having a generic "unsupported build system" pitch gains us, when the specific build systems will all still need to go through the RFC process.

So I must confess that I'm a bit frustrated by this comment, Tom. The reason I'm writing this as a pitch is because the RFC(s) I wrote were determined to be "controversial" even after we had a support policy that explicitly discussed build systems. As far as I can tell, none of the objections raised that made it controversial had to do with Bazel in particular or whether its addition could satisfy the requirements of the support policy, but rather had to do with adding unsupported build systems in general. That was surprising to me, since we'd just had a separate RFC for a support policy, which seems like it would have been the ideal time to raise such objections, but people made the reasonable argument that the writing of that policy was very new (although the policies it recorded were not) and the inclusion of build configurations might reasonably have been missed when people were reviewing it. The prevailing view on the thread seemed to be we should escalate the point about unsupported build systems to come to a decision. So in my mind, this pitch is to make explicit and allow further discussion on the inclusion of unsupported build systems in the support policy, whereas before it was just a sentence that mentioned them as an example. I'm sympathetic to that and don't want to be just slipping things through, but I'd also like to actually make progress here and I feel like we have entered exactly the situation you've described as being opposed to when requesting that we escalate to a pitch: that is a "battle of attrition". I think you've raised reasonable concerns about build system proliferation, and I think we should discuss them, but I'm not sure how me writing yet another iteration of this proposal actually helps us here.

I guess I'm fine making this proposal "Unsupported build systems are allowed and Bazel is, in particular", so we don't have to then do yet another RFC, but my plan was to just reopen the previous RFC and return to the issues of Bazel in particular (and even more specifically our implementation of the LLVM config for it, which I think there were some reasonable criticisms of). I'm worried that discussing the specific case means that if some poor soul wants to add, say, a Meson build or whatever they will have to relitigate these points that have already been decided.

Can you understand where I'm coming from here?

Yes, and I think there may be some misunderstanding here, because the main reason I suggested you include Bazel in this pitch was to try to save your time and energy.

When I first suggested doing a pitch, my assumption was that the RFC for Bazel would turn into a pitch for Bazel and that would be it, however if we proceed with this pitch as written, then we would have had 2 RFCs, 1 Pitch, and still no final decision about Bazel. This seems to me like much more work then what we need to do, not to mention the fact that it is very confusing, and I don't think it's really fair to expect people who object to the original RFC to keep objecting to all these new proposals.

Yeah I appreciate that :-) And I agree that splitting this into separate threads means that it's also harder for people to object and I that that's not fair either.

As I wrote before, I don't really see what a pitch like this would give us. I mean there are negatives to adding Bazel that would be negatives of adding any build systems, so if this pitch is approved, does that mean we aren't allowed to consider these 'generic' negatives when evaluating Bazel?

That is my understanding, yes. If we decide that in general, these negatives are OK as long as certain criteria are met, then I think the only burden on proposals should be "are these criteria met?". But then again, that was my understanding of the point of having a support policy, as well, but that doesn't seem to have solved anything.

I don't want this to be any more complicated than it has to be, and to me the ideal pitch would be: 1) Here are the criteria for adding an unsupported build system and 2) Here is why bazel meets this criteria. I believe you already have most of 1, so just add in 2, and then this can be the final discussion about Bazel.

The thing is that I feel like (1) was covered by the support policy and (2) was basically what I wrote in my last RFC (point by point explaining why I think this meets the description in the support policy). People's subsequent objections seemed almost exclusively about the idea of having unsupported build systems in-tree in general as opposed to anything about Bazel in particular (in addition you had various concerns about the particular implementation that I think are totally something we discuss, but didn't really seem controversial).

So I'm left confused about why we have a pitch at all. If the pitch is about Bazel, then what is controversial about Bazel, specifically? Besides that it's a build system and that for any give build system, many people hate it. Personally I hate CMake *and* Bazel, but I need to build my project so ¯\_(ツ)_/¯

[tstellar]

In D94451#2502977, @GMNGeoffrey wrote:

In D94451#2502917, @tstellar wrote:

In D94451#2502765, @GMNGeoffrey wrote:

In D94451#2496546, @tstellar wrote:

In D94451#2496129, @GMNGeoffrey wrote:

In D94451#2491553, @ctetreau wrote:

Question: Would there be an expectation that unsupported build systems are in a good state for LLVM version branches? If I checkout the git tag for a final LLVM release, should I be able to expect that the build system is functional at that commit?

No. I think there should be no expectation. If the community members who care about the component can figure out a way to make this happen that doesn't make releasing harder for the release manager then they could try to arrange this, but I suspect that's not really possible. I think if that needs to be clearer, it should be clarified in the support policy. https://llvm.org/docs/SupportPolicy.html#peripheral-tier mentions things that aren't "regularly released", but I think that zero expectation of support in releases could be made clearer. Assuming that's already the status quo, I could send it as a patch to the support policy separate from this proposal. Or I could include in this proposal that we'll amend the support policy to reflect that.

In D94451#2495535, @rengolin wrote:

In D94451#2491668, @tstellar wrote:

If this pitch is accepted, then what are the next steps required in order for bazel or another build system to be added to tree? For example, can they automatically be added if they meet the support policy requirements or does there need to be some kind of community ack for? I think the pitch needs to be more clear about what this process is.

This is addressed by https://llvm.org/docs/SupportPolicy.html#inclusion-policy

Yes I'm trying not to duplicate information already in the support policy, where possible.

OK, I think it would be better if this pitch was about adding bazel specifically. I don't really see what having a generic "unsupported build system" pitch gains us, when the specific build systems will all still need to go through the RFC process.

So I must confess that I'm a bit frustrated by this comment, Tom. The reason I'm writing this as a pitch is because the RFC(s) I wrote were determined to be "controversial" even after we had a support policy that explicitly discussed build systems. As far as I can tell, none of the objections raised that made it controversial had to do with Bazel in particular or whether its addition could satisfy the requirements of the support policy, but rather had to do with adding unsupported build systems in general. That was surprising to me, since we'd just had a separate RFC for a support policy, which seems like it would have been the ideal time to raise such objections, but people made the reasonable argument that the writing of that policy was very new (although the policies it recorded were not) and the inclusion of build configurations might reasonably have been missed when people were reviewing it. The prevailing view on the thread seemed to be we should escalate the point about unsupported build systems to come to a decision. So in my mind, this pitch is to make explicit and allow further discussion on the inclusion of unsupported build systems in the support policy, whereas before it was just a sentence that mentioned them as an example. I'm sympathetic to that and don't want to be just slipping things through, but I'd also like to actually make progress here and I feel like we have entered exactly the situation you've described as being opposed to when requesting that we escalate to a pitch: that is a "battle of attrition". I think you've raised reasonable concerns about build system proliferation, and I think we should discuss them, but I'm not sure how me writing yet another iteration of this proposal actually helps us here.

I guess I'm fine making this proposal "Unsupported build systems are allowed and Bazel is, in particular", so we don't have to then do yet another RFC, but my plan was to just reopen the previous RFC and return to the issues of Bazel in particular (and even more specifically our implementation of the LLVM config for it, which I think there were some reasonable criticisms of). I'm worried that discussing the specific case means that if some poor soul wants to add, say, a Meson build or whatever they will have to relitigate these points that have already been decided.

Can you understand where I'm coming from here?

Yes, and I think there may be some misunderstanding here, because the main reason I suggested you include Bazel in this pitch was to try to save your time and energy.

When I first suggested doing a pitch, my assumption was that the RFC for Bazel would turn into a pitch for Bazel and that would be it, however if we proceed with this pitch as written, then we would have had 2 RFCs, 1 Pitch, and still no final decision about Bazel. This seems to me like much more work then what we need to do, not to mention the fact that it is very confusing, and I don't think it's really fair to expect people who object to the original RFC to keep objecting to all these new proposals.

Yeah I appreciate that :-) And I agree that splitting this into separate threads means that it's also harder for people to object and I that that's not fair either.

As I wrote before, I don't really see what a pitch like this would give us. I mean there are negatives to adding Bazel that would be negatives of adding any build systems, so if this pitch is approved, does that mean we aren't allowed to consider these 'generic' negatives when evaluating Bazel?

That is my understanding, yes. If we decide that in general, these negatives are OK as long as certain criteria are met, then I think the only burden on proposals should be "are these criteria met?". But then again, that was my understanding of the point of having a support policy, as well, but that doesn't seem to have solved anything.

I don't want this to be any more complicated than it has to be, and to me the ideal pitch would be: 1) Here are the criteria for adding an unsupported build system and 2) Here is why bazel meets this criteria. I believe you already have most of 1, so just add in 2, and then this can be the final discussion about Bazel.

The thing is that I feel like (1) was covered by the support policy and (2) was basically what I wrote in my last RFC (point by point explaining why I think this meets the description in the support policy). People's subsequent objections seemed almost exclusively about the idea of having unsupported build systems in-tree in general as opposed to anything about Bazel in particular (in addition you had various concerns about the particular implementation that I think are totally something we discuss, but didn't really seem controversial).

So I'm left confused about why we have a pitch at all. If the pitch is about Bazel, then what is controversial about Bazel, specifically? Besides that it's a build system and that for any give build system, many people hate it. Personally I hate CMake *and* Bazel, but I need to build my project so ¯\_(ツ)_/¯

I feel like we've been side-tracked by meta-arguments a lot in this discussion, so I'm going to make a few points and hopefully try to wrap this up.

A. I feel like the pitch should include Bazel for 2 reasons:

1. In the very first RFC, the tone of the discussion turned negative very quickly (and to be clear this was not your fault nor did any of your emails have negative tone). These kinds of discussions discourage people from giving feedback, so it's possible there are valid objections specific to Bazel that we never heard. The LLVM Decision Making Process says:

If a discussion turns controversial, escalate the RFC into a "proposal pitch"

My interpretation of 'controversial' is that it applies to these kinds of discussions, so escalating it into a proposal pitch is appropriate. Also if you look at the "Motivation" section of the LLVM Decision Making Process, it says:

Sometimes people express a loud voice on discussion threads even if they aren't active contributors, and they can derail discussions. There is no "moderator" for these discussions, and no expectations/bounds for them.

Which I believe applies here as well.

2. The "Support Policy" RFC made the discussion confusing and it wasn't clear that in order to object to certain parts of the Bazel RFC you had to also object to the "Support Policy" RFC.

Having said all this, I don't think it's wrong to do an "Unsupported Build System" pitch, and then a Bazel RFC, I just think it would be better to combine them. I'll leave the final decision up to you.

B. In regards to this specific proposal as written, I object to having unsupported build systems in tree, because I believe that they violate the part of the support policy that says:

Code in this [peripheral] tier must not: Negatively affect development of core tier code,

In my opinion, having an alternative build system in the tree negatively affects the CMake build system by diverting resources and attention away from CMake and into the unsupported build systems. And I realize this is still a problem even if the unsupported build system is not in-tree, however, I believe having the build system in-tree makes this issue worse. I think it's debatable how big of a problem this is, and I don't want to spend a lot of energy debating this, because I'm not sure there is any way to prove the magnitude of this problem. I just want the decision makers to consider this view point when making the decision.

That's pretty much all I have to say at this point. Does this help at all? Are you still unsure about how to proceed?

[GMNGeoffrey]

In D94451#2503043, @tstellar wrote:

In D94451#2502977, @GMNGeoffrey wrote:

[snip]

I feel like we've been side-tracked by meta-arguments a lot in this discussion, so I'm going to make a few points and hopefully try to wrap this up.

On that we can certainly agree 😁

A. I feel like the pitch should include Bazel for 2 reasons:

1. In the very first RFC, the tone of the discussion turned negative very quickly (and to be clear this was not your fault nor did any of your emails have negative tone). These kinds of discussions discourage people from giving feedback, so it's possible there are valid objections specific to Bazel that we never heard. The LLVM Decision Making Process says:

If a discussion turns controversial, escalate the RFC into a "proposal pitch"

My interpretation of 'controversial' is that it applies to these kinds of discussions, so escalating it into a proposal pitch is appropriate. Also if you look at the "Motivation" section of the LLVM Decision Making Process, it says:

Sometimes people express a loud voice on discussion threads even if they aren't active contributors, and they can derail discussions. There is no "moderator" for these discussions, and no expectations/bounds for them.

Which I believe applies here as well.

2. The "Support Policy" RFC made the discussion confusing and it wasn't clear that in order to object to certain parts of the Bazel RFC you had to also object to the "Support Policy" RFC.

Having said all this, I don't think it's wrong to do an "Unsupported Build System" pitch, and then a Bazel RFC, I just think it would be better to combine them. I'll leave the final decision up to you.

Thanks for giving your perspective on that; I think it makes sense. I was prepared to write a pitch after the first proposal, but then it seemed like the prevailing opinion was that if we settled the more general questions separately in a support policy we could come back to this. I guess everything got a bit muddied.

B. In regards to this specific proposal as written, I object to having unsupported build systems in tree, because I believe that they violate the part of the support policy that says:

Code in this [peripheral] tier must not: Negatively affect development of core tier code,

In my opinion, having an alternative build system in the tree negatively affects the CMake build system by diverting resources and attention away from CMake and into the unsupported build systems. And I realize this is still a problem even if the unsupported build system is not in-tree, however, I believe having the build system in-tree makes this issue worse. I think it's debatable how big of a problem this is, and I don't want to spend a lot of energy debating this, because I'm not sure there is any way to prove the magnitude of this problem. I just want the decision makers to consider this view point when making the decision.

Thanks for clarifying that. I will make sure to include that concern in the pitch.

That's pretty much all I have to say at this point. Does this help at all? Are you still unsure about how to proceed?

I'm fine making this an "Unsupported Build Systems (and Bazel in Particular)" or "Bazel (with explicit acknowledgement of precedent setting)". I'll wait a bit before writing it up to see if anyone objects to that framing though 😛

[ctetreau]

In D94451#2503412, @GMNGeoffrey wrote:

... "Bazel (with explicit acknowledgement of precedent setting)" ...

This seems productive to me. This has gone on a long time already.

[GMNGeoffrey]

• Rename to be about Bazel specifically
• Add rationale specific to Bazel

[GMNGeoffrey]

In D94451#2512851, @ctetreau wrote:

In D94451#2503412, @GMNGeoffrey wrote:

... "Bazel (with explicit acknowledgement of precedent setting)" ...

This seems productive to me. This has gone on a long time already.

Done. Added content to be about Bazel in particular, while still addressing the general topic. Also added some additional FAQs that came up as part of this review.

[tstellar]

Thanks for the updates. I think this proposal is ready to send to Chris (Step 4).

[GMNGeoffrey]

In D94451#2514407, @tstellar wrote:

Thanks for the updates. I think this proposal is ready to send to Chris (Step 4).

I think we're only supposed to have 4 review managers, so need to trim 1 (other than @lattner), but otherwise agreed.

@lattner can you take a look?

[rengolin]

Overall, I think this is great. It answers all questions I've seen posed on the RFCs and is well aligned with the tiers policy, in text and intent.

Thanks for writing this!

proposals/LP0002-BazelBuildConfiguration.md

235–238

I think this sets a good precedent and is in line with the intent of the tiers policy. Thanks for making it explicit.

[lattner]

This proposal looks really great to me, thank you for writing this up!

[lattner]

For abundance of clarity: I'm accepting this as "something we should merge and then run as a proposal", not saying "this proposal is approved and we should start merging build files" :)

[GMNGeoffrey]

• Fix typo

proposals/LP0002-BazelBuildConfiguration.md

+# Add Bazel Build Configuration to the LLVM Monorepo
+
+*   Proposal:
+    [LP-0002](https://github.com/llvm/llvm-www/blob/master/proposals/LP0002-BazelBuildConfiguration.md)
+*   Author: [Geoffrey Martin-Noble](https://github.com/gmngeoffrey)
+*   Review Managers: [Chris Bieneman](https://github.com/thegreatbeanz),
+    [Eric Christopher](https://github.com/echristo),
+    [Renato Golin](https://github.com/rengolin),
+    [Chris Lattner](https://github.com/lattner),
+    [Geoffrey Martin-Noble](https://github.com/gmngeoffrey),
+    [Tom Stellard](https://github.com/tstellar)
+*   Status: WIP
+*   Pitch thread:
+    [thread](https://lists.llvm.org/pipermail/llvm-dev/2021-January/147745.html)
+*   Previous Discussions
+    [1](http://lists.llvm.org/pipermail/llvm-dev/2020-October/146138.html),
+    [2](http://lists.llvm.org/pipermail/llvm-dev/2020-November/146670.html)
+
+
+## Introduction
+
+LLVM has a single supported build system: CMake. All LLVM components are
+required to build with CMake. It also has an unsupported
+[GN](https://gn.googlesource.com/gn/) build configuration that some developers
+maintain for developer use. The
+[LLVM Support Policy](http://llvm.org/docs/SupportPolicy.html) formalizes the
+different levels of support for components such as this and less involved
+examples like editor configurations. Alternative build systems are already
+mentioned in the Support Policy, but some community members felt the inclusion
+was not thoroughly vetted.
+
+This proposal seeks to add a build configuration for
+[Bazel](https://bazel.build) in the LLVM Monorepo under the "peripheral" support
+tier. Bazel is a build system focused on distributed hermetic and reproducible
+builds. It is used by various projects at Google that depend on LLVM and for
+this purpose these projects have created a Bazel build configuration for LLVM,
+an open source example of which can be found in the
+[llvm-bazel](https://github.com/google/llvm-bazel) repository. Bazel is also
+used by other downstream LLVM users, such as
+[PlaidML](https://github.com/plaidml/plaidml).
+
+While this proposal focuses on Bazel, it also explicitly acknowledges the
+precedent-setting nature of this decision. Since alternative build systems are
+already explicitly mentioned in the Support Policy, this does not require any
+policy change, but might be used as a reference for future RFCs. A GN build
+configuration already exists in tree, but in RFC discussions, some felt that
+"two creates a pattern". This proposal therefore seeks to further define when
+alternative build systems would or would not be accepted into the LLVM monorepo.
+
+This proposal was discussed in this
+[pitch thread](https://lists.llvm.org/pipermail/llvm-dev/2021-January/147745.html).
+
+
+## Motivation
+
+LLVM is widely used and integrated in various downstream projects. Allowing
+alternative build systems in-tree lowers the barrier to entry for these projects
+while adding minimal additional support burden to the community at large. It
+allows collaboration on these configurations that are directly tied to LLVM and
+increases usability of LLVM for downstream projects. Including the build
+configurations in tree greatly simplifies the process of selecting the
+appropriate version of the configuration for building a given LLVM revision. The
+LLVM project also provides a coordination point with neutral governance and
+seems like the correct governance to have for a configuration of LLVM itself.
+
+
+## Proposed solution
+
+A Bazel build configuration for LLVM be checked into the monorepo under
+`llvm/utils/bazel` (adjacent to the current GN files at `llvm/utils/gn`. These
+build files would undergo normal patch review
+([current draft](https://reviews.llvm.org/D90352)).
+
+The Support Policy already clearly outlines the requirements for inclusion in
+the peripheral tier, which include an active subcommunity who can demonstrate
+their commitment to continued maintenance of the component and an RFC to argue
+for its inclusion. This proposal does not seek to change that or open the door
+for any unsupported build system, but rather make the case that Bazel build
+files meet these requirements.
+
+Addressing the points in the support requirements individually:
+
+> Code in this tier must:
+>
+> *   Have a clear benefit for residing in the main repository, catering to an
+>     active sub-community (upstream or downstream).
+
+A number of projects build LLVM with Bazel (e.g. IREE, TensorFlow, PlaidML).
+Google also uses Bazel to build in its internal source repository. This includes
+a substantial number of developers and active contributors to LLVM. Adding this
+to the monorepo would provide a natural coordination point for these projects
+and avoid fragmentation (projects currently have their own copies of the BUILD
+files) or Google-centric governance (e.g. signing Google's CLA).
+
+> *   Be actively maintained by such sub-community and have its problems
+>     addressed in a timely manner.
+
+We can commit to maintaining and addressing issues with the configuration.
+Google has maintained its internal version of this configuration for a few
+years.
+
+> Code in this tier must not:
+>
+> *   Break or invalidate core tier code or infrastructure. If that happens
+>     accidentally, reverting functionality and working on the issues offline is
+>     the only acceptable course of action. There should be no interaction
+>     between the Bazel build configuration and any core code or infrastructure.
+> *   Negatively affect development of core tier code, with the sub-community
+>     involved responsible for making changes to address specific concerns.
+
+This should not affect development of core tier components. Others have raised
+the concern that the existence of an alternative build system might lead to lack
+of maintenance for the CMake build system or reduced contributions from those
+who use the alternatiee build system. Given that supporting CMake will remain a
+requirement and maintenance of a Bazel build system will continue to happen
+regardless (just out of tree), I do not expect any significant impact in this
+way. Some Googlers, including those on my team, do contribute to CMake
+maintenance (e.g.
+https://lists.llvm.org/pipermail/llvm-dev/2021-January/147567.html) and I expect
+will continue to do so. In fact, less friction in maintaining the Bazel build
+files would, I think, make it more likely that build-system-minded folks would
+turn their attention to CMake.
+
+> *   Negatively affect other peripheral tier code, with the sub-communities
+>     involved tasked to resolve the issues, still making sure the solution
+>     doesn’t break or invalidate the core tier.
+
+Similarly, this should have no interaction with other components in the
+peripheral tier. The LLVM Bazel build system maintainers will address conflicts
+if they arise.
+
+> *   Impose sub-optimal implementation strategies on core tier components as a
+>     result of idiosyncrasies in the peripheral component.
+
+We do not expect any negative constraints on normal development of core tiers.
+Bazel is stricter about layering, which may help quickly identify layering
+issues in incoming commits, which is already a development principle that LLVM
+espouses.
+
+> *   Have build infrastructure that spams all developers about their breakages.
+>     Build infrastructure will be configured to only notify opted-in
+>     developers.
+> *   Fall into disrepair. This is a reflection of lack of an active
+>     sub-community and will result in removal.
+
+Build bots with accompanying status badges will be prominently linked from the
+README. Currently a Linux/Clang build bot exists and can be easily reconfigured
+after the code move. Additional build bots can be added based on supported
+configurations (likely Windows MSVC and MacOS as early additions).
+
+> Code in this tier should:
+>
+> *   Have infrastructure to test, whenever meaningful, with either no warnings
+>     or notification contained within the sub-community.
+> *   Have support and testing that scales with the complexity and resilience of
+>     the component, with the bar for simple and gracefully-degrading components
+>     (such as editor bindings) much lower than for complex components that must
+>     remain fresh with HEAD (such as experimental back-ends or alternative
+>     build systems).
+
+Build bot coverage already exists and will be expanded as described above.
+
+> *   Have a document making clear the status of implementation, level of
+>     support available, who the sub-community is and, if applicable, roadmap
+>     for inclusion into the core tier.
+
+The patch includes a README that should make the support level clear. I am happy
+to add additional language or take additional steps to make that more clear
+(e.g. adding `unsupported` to the directory path).
+
+> *   Be restricted to a specific directory or have a consistent pattern (ex.
+>     unique file suffix), making it easy to remove when necessary.
+
+All configuration is restricted to a single directory and should be trivial to
+remove.
+
+
+## Impact On Other Projects
+
+Downstream projects that rely on other build systems would benefit from being
+able to collaborate on build configurations of LLVM using systems other than the
+supported LLVM build system (currently CMake).
+
+Additional commit traffic could be noisy. If this becomes a significant problem
+it would be necessary to rectify the situation to the satisfaction of the
+community. Some mitigations have already been proposed in various discussion
+threads.
+
+Similarly, increased commit traffic increases the risk of merge conflicts when
+cherry-picking for release. Since there is no expectation that peripheral
+components will be functional in releases, these merge conflicts could be
+resolved in any arbitrary fashion, which should minimize their cost. If they
+nevertheless create a problem, the subcommunity maintaining an alternative
+build system would need to adopt technical or policy changes to rectify the
+situation when it is brought to their attention.
+
+New additions to the repo increase the size of the LLVM checkout. These
+configurations are a tiny fraction of the overall size of LLVM. Comparing the
+LLVM 11.0 release to the latest llvm-bazel, the Bazel build configuration would
+be about 0.05 % of the overall repository archive, compressed or expanded.
+
+
+## Frequently Asked Questions
+
+**Q: How does the outcome of this proposal affect the existing GN build
+configuration?**
+
+A: Given that GN is already an existing component, the introduction of which
+went through the normal RFC process, any alterations to it should be brought
+forward and discussed in a separate RFC.
+
+
+**Q: Why not maintain the build configurations in a separate repo with an LLVM
+submodule?**
+
+A: This is certainly *feasible* and is in fact how
+https://github.com/google/llvm-bazel works today. It even has some advantages,
+like the ability to guarantee that the build configuration passed for a given
+commit. It comes with significant complications, however: it requires an
+entirely separate contribution process that needs logic to ensure that new
+patches be attached to the correct commit. It also complicates fetching the
+correct version of the configuration. In particular the Bazel method for
+fetching a new archive via
+[http_archive](https://docs.bazel.build/versions/master/repo/http.html#http_archive)
+does the fetch at build time and caches based on the SHA-256 digest of the
+archive. This adds an extra layer of complexity to vending a build configuration
+for an LLVM commit because it expects it to remain stable over time.
+
+**Q: Would there be an expectation that the Bazel build is in a good state for
+LLVM version branches? If I checkout the git tag for a final LLVM release,
+should I be able to expect that the Bazel build system is functional at that
+commit?**
+
+No. I think there should be no such expectation. If the community members who
+care about the component would like releases to have functioning build files,
+they can figure out a way to make this happen that doesn't make releasing harder
+for the release manager (e.g. submitting patches to the release branch). I am
+not currently aware of anyone who would want to build LLVM with Bazel against a
+release (our development against LLVM is very active, so we tend to want HEAD).
+
+**Q: Why not just embed the CMake build in Bazel?**
+
+Bazel theoretically has support for this via
+[rules_foreign_cc](https://github.com/bazelbuild/rules_foreign_cc), but this is
+an experimental and unsupported project and the last attempt we made to use it
+for LLVM was unsuccessful, which is why OSS projects that use LLVM and Bazel
+tend to instead have a Bazel configuration for LLVM. Bazel also likes to know
+about all sources and is able to parallelize for distributed builds when doing
+so, so there are additional benefits for using such a configuration. Finally,
+even if embedding CMake were to work, it is likely that internally Google would
+continue to use the internal variant of Bazel and would therefore continue to
+maintain BUILD files for it. Thus the marginal effort for maintaining the files
+in OSS is not as great.
+
+**Q: What are the concrete next steps for Bazel inclusion if this proposal is
+accepted?**'
+
+Discussion of the particular implementation would happen as part of patch
+review.
+
+## Alternatives considered
+
+LLVM could refuse to accept unsupported build configurations. Users interested
+in other build systems would need to continue working out their own solutions.
+This would obviously not be catastrophic, but seems like a missed opportunity to
+lower the barrier to entry for integrating LLVM into downstream projects.
+
+LLVM could also accept unsupported build configurations, but have them in a
+separate repository instead of the monorepo. This helps deal with concerns over
+neutral and standard governance of build configurations that matches that of
+LLVM itself. It does not alleviate coordination problems contributing to and
+fetching these configurations while keeping them tied to specific LLVM commits,
+however.