llvm dev - Mar 2021 - [PROPOSAL] Add Bazel Build Configuration to the LLVM Monorepo

On 2/9/21 10:00 PM, Geoffrey Martin-Noble wrote:
> To expand a bit on Eric's response, the intent here is *not* to make
Bazel
> a supported build system for LLVM or to replace CMake (which I believe the
> proposal makes clear), but rather to enable Bazel usage and shared
> configuration for people and projects that already use it. I do not expect
> that Bazel will cover all the use cases currently supported by LLVM CMake
> any time soon (ever?).I don't work on Bazel itself, so have no insight
on
> the support plan for those architectures. Only developers interested in
> working with Bazel would be expected to use or update the configuration, so
> lack of support for specific architectures should not affect things, I
> think.
Looking at the amount of copy-and-paste code in Bazel [1], I'm not really
convinced
that the code quality of Bazel speaks for itself.

Also, my personal experience with sending patches to Google projects so far has
been
rather underwhelming. Usually, Google projects did not accept any patches for
use
cases that are not of Google's own interested such as better support for
big-endian
targets [2]. On the other hand, Google engineers expect upstream projects to add
support for technology Google uses internally.

I wish it would be more balanced and Google would allow patches in Chromium or
V8
to support more architectures if - on the other hand - they ask other upstream
projects to carry support for their usecases.

Adrian
> [1]
https://github.com/bazelbuild/bazel/commit/1c29dff364fd34d7e6158c812cfd6d96f66be747
> [2] https://catfox.life/2021/03/21/really-leaving-the-linux-desktop-behind/
-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz at debian.org
`. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

(full disclosure, I am a Google employee)

I don't think this is appropriate content, communication, or tone for the
LLVM community.

On Wed, Mar 24, 2021 at 12:39 AM John Paul Adrian Glaubitz via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> On 2/9/21 10:00 PM, Geoffrey Martin-Noble wrote:
> > To expand a bit on Eric's response, the intent here is *not* to
make
> Bazel
> > a supported build system for LLVM or to replace CMake (which I believe
> the
> > proposal makes clear), but rather to enable Bazel usage and shared
> > configuration for people and projects that already use it. I do not
> expect
> > that Bazel will cover all the use cases currently supported by LLVM
CMake
> > any time soon (ever?).I don't work on Bazel itself, so have no
insight on
> > the support plan for those architectures. Only developers interested
in
> > working with Bazel would be expected to use or update the
configuration,
> so
> > lack of support for specific architectures should not affect things, I
> > think.
>
> Looking at the amount of copy-and-paste code in Bazel [1], I'm not
really
> convinced
> that the code quality of Bazel speaks for itself.
>
This patch doesn't seem to me to be reflective of "good" or
"bad" code, nor
has anyone made any claim about the code quality of Bazel. It isn't
relevant to this discussion.

> Also, my personal experience with sending patches to Google projects so
> far has been
> rather underwhelming. Usually, Google projects did not accept any patches
> for use
> cases that are not of Google's own interested such as better support
for
> big-endian
> targets [2]. On the other hand, Google engineers expect upstream projects
> to add
> support for technology Google uses internally.
>
> I wish it would be more balanced and Google would allow patches in
> Chromium or V8
> to support more architectures if - on the other hand - they ask other
> upstream
> projects to carry support for their usecases.
> [1]
>
https://github.com/bazelbuild/bazel/commit/1c29dff364fd34d7e6158c812cfd6d96f66be747
> [2]
> https://catfox.life/2021/03/21/really-leaving-the-linux-desktop-behind/

These seem like unhelpful ad-hominem criticisms that aren't relevant to the
matter being discussed. This proposal has been specifically designed to be
minimally impactful to the community (should only be "there are some more
commits to the project/more commit list emails" - and if gn is anything to
go by, not many (<0.1% I'd wager, at a rough guess)).

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