llvm dev - Oct 2020 - Contributing Bazel BUILD files similar to gn

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.

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

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?

Thanks.

-- 
Stefan Teleman
stefan.teleman at gmail.com

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>

On Thu, Oct 29, 2020 at 9:12 PM David Blaikie <dblaikie at gmail.com>
wrote:

>> 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.
I fail to see how any of these are technical facts. Whatever "variety
of other projects with LLVM as a dependency" choose to use for their
build system is their business.

Let's be a bit more precise here: this "variety of other projects with
LLVM as a dependency" aren't just random projects off the Internet.
These are all Google projects. Correct?

So, in final analysis, this has nothing to do with Bazel's technical
merits. It has everything to do with "It's convenient for Google".
Regardless of whether the larger LLVM community agrees with the idea,
or not. Which, so far, it does not seem to me that it has.

Thanks for clarifying.

-- 
Stefan Teleman
stefan.teleman at gmail.com

On Thu, Oct 29, 2020 at 4:49 PM Stefan Teleman via llvm-dev <
llvm-dev at lists.llvm.org> 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.
>
> 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.
>
I don't think anyone tried to convince you otherwise, but we're not
trying
to replace CMake here, not even put Bazel there as something that would be
supported on any level close to CMake.
So I'm puzzled by this angle you're pushing?


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

The intent behind Bazel is that it offers different functionalities than
CMake (I explained my perception of some of them earlier in the thread:
http://lists.llvm.org/pipermail/llvm-dev/2020-October/146182.html ).
Does it make it strictly "a better alternative to CMake"? I don't
think so.
But why should we debate the "intent behind Bazel"?
The reality is just that it exists, and that other OSS projects are using
it for whatever reasons.


> 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".
>
> 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 is a user-base out-there that can't easily depend on the CMake
config we provide, *and* there are upstream maintainers that step up to
maintain it, why not?

>
> Thanks.
>
> --
> Stefan Teleman
> stefan.teleman at gmail.com
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20201029/13a2e69c/attachment.html>