<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 29, 2020 at 4:49 PM Stefan Teleman <<a href="mailto:stefan.teleman@gmail.com">stefan.teleman@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu, Oct 29, 2020 at 7:16 PM David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:<br>
<br>
> I expect most of it is probably a statement free of value judgments: Some other projects chose to use it/some folks have to use it for other reasons, clearly there's enough use that it's motivated folks to have/maintain Bazel builds for LLVM for years. Rather than judging their choices as bad/lesser/wrong - might be useful to accept that some folks had their reasons and they're trying to make the most of the situation. I don't think anyone's making an argument that LLVM should switch to Bazel/that that would be better than the CMake we're using, and I think it's helpful to return the favor and not suggest that other projects would be better off switching to CMake over Bazel - they no doubt have their reasons.<br>
<br>
Please do not manufacture statements that I did not make. I never<br>
suggested, or stated, anywhere, that some other imaginary project<br>
using Bazel should switch to CMake.<br></blockquote><div><br></div><div>Sorry, that seems to be the question though - other projects that have llvm as a dependency use Bazel. No one suggested that Bazel was better than CMake or that Bazel should be used instead of CMake.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I did state that I do not find Bazel to be a better alternative to<br>
CMake. My statement is based on direct experience with both. </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
If the intent behind Bazel is not to present it as a better<br>
alternative to CMake, then what is the intent?</blockquote><div><br>The original proposal seemed to outline the intent and motivation - that other projects with LLVM as a dependency use Bazel and would benefit from having Bazel build files for LLVM in a central place to work on them - not to replace the CMake build system. Same as the 'gn' integration - no one's suggesting it's better, just that it's what some other projects that use as LLVM as a dependency do use Bazel.<br><br>"<span style="font-variant-numeric:normal;font-variant-east-asian:normal;background-color:transparent;font-size:11pt;font-family:Roboto,sans-serif;color:rgb(66,66,66);vertical-align:baseline;white-space:pre-wrap">As you may know, Google uses Bazel internally and has maintained a Bazel BUILD of LLVM for years. Especially with the introduction of MLIR, we've got more and more OSS projects with a Bazel BUILD depending on LLVM (e.g. </span><a href="https://github.com/google/iree" target="_blank" style="text-decoration-line:none"><span style="font-size:11pt;font-family:Roboto,sans-serif;background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;text-decoration-line:underline;vertical-align:baseline;white-space:pre-wrap">IREE</span></a><span style="font-variant-numeric:normal;font-variant-east-asian:normal;background-color:transparent;font-size:11pt;font-family:Roboto,sans-serif;color:rgb(66,66,66);vertical-align:baseline;white-space:pre-wrap"> and </span><a href="https://github.com/tensorflow/tensorflow" target="_blank" style="text-decoration-line:none"><span style="font-size:11pt;font-family:Roboto,sans-serif;background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;text-decoration-line:underline;vertical-align:baseline;white-space:pre-wrap">TensorFlow</span></a><span style="font-variant-numeric:normal;font-variant-east-asian:normal;background-color:transparent;font-size:11pt;font-family:Roboto,sans-serif;color:rgb(66,66,66);vertical-align:baseline;white-space:pre-wrap">). We're also not the only ones using Bazel: e.g. PlaidML also has a Bazel BUILD of LLVM that they've </span><a href="https://github.com/plaidml/plaidml/blob/master/vendor/llvm/llvm.BUILD" target="_blank" style="text-decoration-line:none"><span style="font-size:11pt;font-family:Roboto,sans-serif;background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;text-decoration-line:underline;vertical-align:baseline;white-space:pre-wrap">borrowed from TF</span></a><span style="font-variant-numeric:normal;font-variant-east-asian:normal;background-color:transparent;font-size:11pt;font-family:Roboto,sans-serif;color:rgb(66,66,66);vertical-align:baseline;white-space:pre-wrap">. Each of these projects has to jump through some weird hoops to keep their version of the Bazel BUILD files in sync with the code, which requires </span><span style="font-variant-numeric:normal;font-variant-east-asian:normal;font-size:10.5pt;font-family:Roboto,sans-serif;color:rgb(60,64,67);vertical-align:baseline;white-space:pre-wrap">some fragile combination of scripts and human intervention. </span><span style="font-variant-numeric:normal;font-variant-east-asian:normal;background-color:transparent;font-size:11pt;font-family:Roboto,sans-serif;color:rgb(66,66,66);vertical-align:baseline;white-space:pre-wrap">Instead, we'd like to move general-purpose Bazel BUILD files into the LLVM Project monorepo. We expect to follow the model of the GN build where these will be maintained by interested contributors rather than expecting the general community to maintain them."</span><br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> Instead of maintaining<br>
this impenetrable mystery as to why a Bazel build system should be<br>
included in LLVM, please take the time to advocate for Bazel with<br>
technical facts, than "someone at Google really likes it".<br></blockquote><div><br>That's the technical facts though: A variety of other projects with LLVM as a dependency use Bazel, for whatever their reasons, and are currently maintaining Bazel build files out of tree and it would be easier for them to coordinate in-tree instead.<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Just because someone likes and maintains an alternative build system<br>
for LLVM, somewhere, that does not automatically mean, or imply that<br>
it should be upstreamed.<br>
<br>
For all I know, someone might be building their fork of LLVM with<br>
autoconf. I am sure they have their own very good reasons for doing<br>
so. Should we, therefore, bring back autoconf?<br></blockquote><div><br>If there were a diversity of involved parties and they were proposing to add it in the same way as the gn build system (importantly: not the same way autoconf was maintained previously, where it was on equal footing with the CMake build - with emailing buildbots, etc) - yeah, that seems plausible to me.<br><br>- Dave </div></div></div>