Page MenuHomePhabricator

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

Authored by GMNGeoffrey on Jan 11 2021, 2:11 PM.

Diff Detail

Repository
rW llvm-www

Event Timeline

GMNGeoffrey requested review of this revision.Jan 11 2021, 2:11 PM
GMNGeoffrey created this revision.
GMNGeoffrey edited the summary of this revision. (Show Details)Jan 11 2021, 2:15 PM
  • Add links to pitch thread now that it exists

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?

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 added inline comments.
proposals/LP0002-UnsupportedBuildConfigurations.md
72 ↗(On Diff #315936)
121 ↗(On Diff #315936)
140 ↗(On Diff #315936)
beanz added a subscriber: beanz.Jan 12 2021, 9:15 PM

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.

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

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.

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.

  • Fix typos
GMNGeoffrey marked 4 inline comments as done.Jan 13 2021, 9:33 AM
GMNGeoffrey added inline comments.
proposals/LP0002-UnsupportedBuildConfigurations.md
140 ↗(On Diff #315936)

I really suck at spelling unsupported, huh?

GMNGeoffrey marked an inline comment as done.Jan 13 2021, 9:34 AM

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.

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.

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.

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]")

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.

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?

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.

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.

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.

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 ¯\_(ツ)_/¯

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.

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.

  1. 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?

[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.

  1. 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 😛

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

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

  • Rename to be about Bazel specifically
  • Add rationale specific to Bazel
GMNGeoffrey retitled this revision from Proposal for allowing unsupported build system configuration in-tree to Proposal for add Bazel build configuration in-tree with peripheral support.Jan 21 2021, 6:41 PM
GMNGeoffrey retitled this revision from Proposal for add Bazel build configuration in-tree with peripheral support to Proposal for adding Bazel build configuration in-tree with peripheral support.

... "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.

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

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?

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 accepted this revision.Jan 31 2021, 6:01 PM

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

This revision is now accepted and ready to land.Jan 31 2021, 6:01 PM

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" :)