diff --git a/proposals/LP0002-UnsupportedBuildConfigurations.md b/proposals/LP0002-UnsupportedBuildConfigurations.md new file mode 100644 --- /dev/null +++ b/proposals/LP0002-UnsupportedBuildConfigurations.md @@ -0,0 +1,145 @@ +# Allow Unsupported Build Configurations in the LLVM Monorepo + +* Proposal: + [LP-0002](https://github.com/llvm/llvm-www/blob/master/proposals/LP0002-UnsupportedBuildConfigurations.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, so this proposal seeks to come to a decision on that +point in particular. + +The motivating example is [Bazel](https://bazel.build), 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 (https://github.com/google/llvm-bazel). It is +also used by other downstream LLVM users, such as +[PlaidML](https://github.com/plaidml/plaidml). + +This proposal suggests that alternative build systems be accepted in the +monorepo in the "peripheral" support tier. + +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 give 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 + +LLVM explicitly acknowledges unsupported build systems as a component allowed in +tree under the peripheral support tier outlined in the LLVM Support Policy. +Alternative build systems are already mentioned in the Support Policy, but some +community members felt the inclusion was not thoroughly vetted, so this proposal +seeks to come to a decision on that point in particular. + +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 unuspported build system, but rather make it clear that the community +will accept unsupported build systems on principle, provided they meet the +requirements already outlined in the Support Policy. + +It does not seem that the support policy needs any modifications to reflect +the potential inclusion of unsupported buils systems, so this proposal would +only codify a specific interpretation of the policy. + + +## 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 guarnatee 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. + + +## 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 unuspported 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.