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

> This is a fairly unhelpful email - clearly folks using Bazel derive some
benefit/have chosen some tradeoff compared to CMake. Doesn't have to be the
thing you want, but it's pretty unhelpful to dismiss/diminish the needs of
others like this.
I did not see a rationale for the Bazel proposal, outlining its
benefits over CMake.

Speaking with direct experience with Bazel - Tensorflow - I cannot
think of a single reason why it would/should be considered "better"
over the current CMake.

Everyone has their own favorite build system. That is nice, but it is
not enough of a reason to propose adding it.

I would also like to become informed as to what particular
needs/shortcomings/defects are addressed by Bazel, that are lacking in
/ cannot be addressed by CMake.

Thanks.

-- 
Stefan Teleman
stefan.teleman at gmail.com

On Thu, 29 Oct 2020 at 19:41, Stefan Teleman via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Everyone has their own favorite build system. That is nice, but it is
> not enough of a reason to propose adding it.
>
> I would also like to become informed as to what particular
> needs/shortcomings/defects are addressed by Bazel, that are lacking in
> / cannot be addressed by CMake.
>
I don't think they're proposing adding Bazel as a new core build system
nor
replacing CMake.

This is just about adding Bazel files to the project so external projects
(like Tensorflow) can build LLVM more easily. Also, so that all Bazel-based
builds that use LLVM can share the same files without having to reproduce
them in every sub-project.

It is a worthy goal in itself, but I think this speaks very loudly to how
weird it is to build LLVM. We had to add some horrible hacks on our project
because exporting CMake and TD files to our project (in order to use MLIR)
was super weird.

So, perhaps there's an underlying goal there to finally fix the LLVM build
"once and for all", and export libraries, headers, and meta-files in
an
orderly fashion, so that wrapping projects don't need to care what build
system LLVM is in.

But I'm not a build-system specialist, so I can't even begin to fathom
how
that would work. I'm not even sure that's possible, so... lots of salt.

In the meantime, having those files wouldn't be the end of the world. But I
fear that once we add, they'll stay there forever, and will lead to people
ignoring CMake and segregating the project.

cheers,
--renato
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20201029/3a063e2a/attachment.html>

On Thu, Oct 29, 2020 at 3:57 PM Renato Golin <rengolin at gmail.com>
wrote:
>
> In the meantime, having those files wouldn't be the end of the world.
But I fear that once we add, they'll stay there forever, and will lead to
people ignoring CMake and segregating the project.
Yes that is my main concern as well.

Build systems for complex projects are ... messy. I believe that what
we have right now - with CMake - works quite well. And I am perfectly
aware of the insane amount of work that has gotten into making LLVM
quite easy to build.

-- 
Stefan Teleman
stefan.teleman at gmail.com

On Thu, Oct 29, 2020 at 12:41 PM Stefan Teleman <stefan.teleman at
gmail.com>
wrote:
> > This is a fairly unhelpful email - clearly folks using Bazel derive
some
> benefit/have chosen some tradeoff compared to CMake. Doesn't have to be
the
> thing you want, but it's pretty unhelpful to dismiss/diminish the needs
of
> others like this.
>
> I did not see a rationale for the Bazel proposal, outlining its
> benefits over CMake.
>
> Speaking with direct experience with Bazel - Tensorflow - I cannot
> think of a single reason why it would/should be considered
"better"
> over the current CMake.
>
> Everyone has their own favorite build system. That is nice, but it is
> not enough of a reason to propose adding it.
>
> I would also like to become informed as to what particular
> needs/shortcomings/defects are addressed by Bazel, that are lacking in
> / cannot be addressed by CMake.
>
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.

- Dave

>
> Thanks.
>
> --
> Stefan Teleman
> stefan.teleman at gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20201029/97f9a935/attachment.html>

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