<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal">Since this is being added within the bounds of a now-existing policy, I will withdraw my objections. Thanks for tabling discussion of adding Bazel until the policy on peripheral tier components was settled, and thanks very much to Renato
for taking the initiative to push through a new policy!<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Unfortunately, I do not know enough about Bazel to provide any sort of useful code review.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Thanks,<o:p></o:p></p>
<p class="MsoNormal"> Christopher Tetreault<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><b>From:</b> llvm-dev <llvm-dev-bounces@lists.llvm.org> <b>On Behalf Of
</b>Geoffrey Martin-Noble via llvm-dev<br>
<b>Sent:</b> Monday, November 16, 2020 7:02 PM<br>
<b>To:</b> LLVM Dev <llvm-dev@lists.llvm.org><br>
<b>Subject:</b> [EXT] [llvm-dev] RFC: Contributing Bazel BUILD files in the "peripheral" support tier<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">I <a href="https://groups.google.com/g/llvm-dev/c/u07o3QREVUg/%20">
previously</a> proposed contributing Bazel build files to the LLVM monorepo, supported *only* by interested community members and not to interfere with or affect the existing CMake configuration. As part of that conversation, it became clear that the LLVM policies
for more "peripheral" components were not clearly documented. We now have a shiny new
<a href="http://llvm.org/docs/SupportPolicy.html">Support Policy</a>. Thank you, Renato for moving that forward. Please take a look at it, if you haven't already.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I would now like to re-raise the proposal to contribute Bazel build files to the LLVM monorepo. I am starting a new thread, as the last one became rather fragmented.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">This build configuration would be added at the <a href="http://llvm.org/docs/SupportPolicy.html#peripheral-tier">
peripheral support level</a> to a new `utils/bazel` directory. I've prepared a <a href="https://reviews.llvm.org/D90352">
patch</a> of what I am proposing to add. It includes a README indicating the level of support. It is largely a port of the Bazel build files Google uses internally and has maintained for several years.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">This should have approximately the same impact on the community as the current GN build in `llvm/utils/gn` does today. That is, it should not affect anyone who doesn't care.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I've commented on the specific <a href="http://llvm.org/docs/SupportPolicy.html#id2">
requirements</a> listed in the support policy inline:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal">Code in this tier must:<o:p></o:p></p>
</blockquote>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal"> <o:p></o:p></p>
</blockquote>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal">* Have a clear benefit for residing in the main repository, catering to an active sub-community (upstream or downstream).<o:p></o:p></p>
</blockquote>
<div>
<p class="MsoNormal">A number of projects build LLVM with Bazel (e.g. <a href="https://github.com/google/iree">
IREE</a>, <a href="https://github.com/tensorflow/tensorflow">TensorFlow</a>, <a href="https://github.com/plaidml/plaidml/blob/master/vendor/llvm/llvm.BUILD">
PlaidML</a>). 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).<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal">* Be actively maintained by such sub-community and have its problems addressed in a timely manner.<o:p></o:p></p>
</blockquote>
<div>
<p class="MsoNormal">We can commit to maintaining and addressing issues with the configuration. Google has maintained its internal version of this configuration for a few years.<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal"> <o:p></o:p></p>
</blockquote>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal">Code in this tier must not:<br>
* 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.<o:p></o:p></p>
</blockquote>
<div>
<p class="MsoNormal">There should be no interaction between the Bazel build configuration and any core code or infrastructure.<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal">* Negatively affect development of core tier code, with the sub-community involved responsible for making changes to address specific concerns.<o:p></o:p></p>
</blockquote>
<div>
<p class="MsoNormal"> This should not affect development of core tier components. One reason we propose adding this to the root utils/ directory instead of under llvm/utils (where GN is located) is to avoid unnecessarily sending messages to llvm-commits. Others
have raised the concern that the existence of an alternative build system might lead to lack of maintenance for the CMake build system. Given that supporting CMake will remain a requirement and maintenance of a Bazel build system will continue to happen regardless,
we do not expect any significant impact in this way.<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal">* 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.<o:p></o:p></p>
</blockquote>
<div>
<p class="MsoNormal">Similarly, this should have no interaction with other components in the peripheral tier. We will address conflicts if they arise. <o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal">* Impose sub-optimal implementation strategies on core tier components as a result of idiosyncrasies in the peripheral component.<o:p></o:p></p>
</blockquote>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal">* Have build infrastructure that spams all developers about their breakages.<o:p></o:p></p>
</blockquote>
<div>
<p class="MsoNormal">Build infrastructure will be configured to only notify opted-in developers. <o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal">* Fall into disrepair. This is a reflection of lack of an active sub-community and will result in removal.<o:p></o:p></p>
</blockquote>
<div>
<p class="MsoNormal">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. A windows build bot will be added soon.<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal"> <o:p></o:p></p>
</blockquote>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal">Code in this tier should:<br>
* Have infrastructure to test, whenever meaningful, with either no warnings or notification contained within the sub-community.<o:p></o:p></p>
</blockquote>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal">* 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).<o:p></o:p></p>
</blockquote>
<div>
<p class="MsoNormal">Build bot coverage already exists and will be expanded as described above. <o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal">* 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.<o:p></o:p></p>
</blockquote>
<div>
<p class="MsoNormal">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).<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal">* Be restricted to a specific directory or have a consistent pattern (ex. unique file suffix), making it easy to remove when necessary.<o:p></o:p></p>
</blockquote>
<div>
<p class="MsoNormal">All configuration is restricted to a single directory and should be trivial to remove.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">A number of people raised the question of "why not a separate repository". This is indeed possible: It's what we've done with <a href="https://github.com/google/llvm-bazel">https://github.com/google/llvm-bazel</a>, which is currently used
by <a href="https://github.com/google/iree">https://github.com/google/iree</a>. It is significantly more infrastructure, coordination, and complexity for something that is specifically a configuration for the LLVM project itself, not its own dependent or adjacent
project.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<div>
<p class="MsoNormal">I believe this contribution will significantly improve the situation for downstream users that use Bazel while having minimal impact on the community at large.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Thanks,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Geoffrey<o:p></o:p></p>
</div>
</div>
</div>
</div>
</body>
</html>