[llvm-dev] Contributing Bazel BUILD files similar to gn

David Blaikie via llvm-dev llvm-dev at lists.llvm.org
Thu Oct 29 18:11:58 PDT 2020


On Thu, Oct 29, 2020 at 4:49 PM Stefan Teleman <stefan.teleman at gmail.com>
wrote:

> On Thu, Oct 29, 2020 at 7:16 PM David Blaikie <dblaikie at gmail.com> wrote:
>
> > 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.
>
> Please do not manufacture statements that I did not make. I never
> suggested, or stated, anywhere, that some other imaginary project
> using Bazel should switch to CMake.
>

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.


> I did state that I do not find Bazel to be a better alternative to
> CMake. My statement is based on direct experience with both.


> If the intent behind Bazel is not to present it as a better
> alternative to CMake, then what is the intent?


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.

"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.
IREE <https://github.com/google/iree> and TensorFlow
<https://github.com/tensorflow/tensorflow>). We're also not the only ones
using Bazel: e.g. PlaidML also has a Bazel BUILD of LLVM that they've borrowed
from TF
<https://github.com/plaidml/plaidml/blob/master/vendor/llvm/llvm.BUILD>.
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 some
fragile combination of scripts and human intervention. 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."


> Instead of maintaining
> this impenetrable mystery as to why a Bazel build system should be
> included in LLVM, please take the time to advocate for Bazel with
> technical facts, than "someone at Google really likes it".
>

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.


> Just because someone likes and maintains an alternative build system
> for LLVM, somewhere, that does not automatically mean, or imply that
> it should be upstreamed.
>
> For all I know, someone might be building their fork of LLVM with
> autoconf. I am sure they have their own very good reasons for doing
> so. Should we, therefore, bring back autoconf?
>

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.

- Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20201029/1f0045d3/attachment.html>


More information about the llvm-dev mailing list