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

On Thu, 29 Oct 2020 at 15:23, Tom Stellard via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> I'm a little concerned about having two 'unsupported'
buildsystems
> living in tree, and I'm not sure what would stop us from continuing to
> add more.  I would feel better if we had a set of guidelines to define
> the criteria for adding a new buildsytem and also criteria for when we
> can remove them.

I have used Bazel and it doesn't seem to map well to CMake. It seems to be
in between CMake and Ninja with a lot of hard-coded dependencies that are
cumbersome to keep updating. I'm by no means an expert, and I could very
well be wrong, but supporting more than one build system is not trivial
(remember the autoconf days?).

For example, when trying to implement the same logic on both will not be
trivial. So, whenever we want to add some functionality or improve how we
build LLVM with one system, we'll have to do so in multiple build systems
that do not easily match each other. If we don't try to match
functionality, we'll segregate the community, because people will be able
to do X on build system A but not B, and the similar features cluster
together and then we have essentially two projects built from the same
source code.

Testing this, or worse, trying to fix a buildbot that is built with Bazel
(and having to install Java JDK and all its dependencies) on potentially a
hardware that you do not have access to, will be a nightmare to debug. The
nature of post-commit testing, revert and review of LLVM will not make that
simpler. Unless we treat the Bazel build as "not our problem" (which
defeats the point of having it?).

To make matters worse, our CMake files are not simple, and do not do all of
the things we want them to do in the way we understand completely. There is
a lot of kludge that we carry and with that comes in two categories: the
things that we hate and would love to fix, and the things that are fixes
that we have no idea are there. The former are the reasons why people want
to start a new build system, the latter is why they soon realise that was a
mistake (insert XKCD joke here).

If the Bazel files can be completely ignored, then it's just more clutter.
But if other projects start to use more different build systems and we
start packing them all in LLVM, then we'll have a hard time knowing what we
build how. I can't really see this scaling.

Two-cents worth.
--renato
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20201029/973cd48b/attachment.html>

On Thu, Oct 29, 2020 at 9:06 AM Renato Golin via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> On Thu, 29 Oct 2020 at 15:23, Tom Stellard via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> I'm a little concerned about having two 'unsupported'
buildsystems
>> living in tree, and I'm not sure what would stop us from continuing
to
>> add more.  I would feel better if we had a set of guidelines to define
>> the criteria for adding a new buildsytem and also criteria for when we
>> can remove them.
>
>
> I have used Bazel and it doesn't seem to map well to CMake. It seems to
be
> in between CMake and Ninja with a lot of hard-coded dependencies that are
> cumbersome to keep updating. I'm by no means an expert, and I could
very
> well be wrong, but supporting more than one build system is not trivial
> (remember the autoconf days?).
>
> For example, when trying to implement the same logic on both will not be
> trivial. So, whenever we want to add some functionality or improve how we
> build LLVM with one system, we'll have to do so in multiple build
systems
> that do not easily match each other. If we don't try to match
> functionality, we'll segregate the community, because people will be
able
> to do X on build system A but not B, and the similar features cluster
> together and then we have essentially two projects built from the same
> source code.
>
> Testing this, or worse, trying to fix a buildbot that is built with Bazel
> (and having to install Java JDK and all its dependencies) on potentially a
> hardware that you do not have access to, will be a nightmare to debug. The
> nature of post-commit testing, revert and review of LLVM will not make that
> simpler. Unless we treat the Bazel build as "not our problem"
(which
> defeats the point of having it?).
>
> To make matters worse, our CMake files are not simple, and do not do all
> of the things we want them to do in the way we understand completely. There
> is a lot of kludge that we carry and with that comes in two categories: the
> things that we hate and would love to fix, and the things that are fixes
> that we have no idea are there. The former are the reasons why people want
> to start a new build system, the latter is why they soon realise that was a
> mistake (insert XKCD joke here).
>
> If the Bazel files can be completely ignored, then it's just more
clutter.
> But if other projects start to use more different build systems and we
> start packing them all in LLVM, then we'll have a hard time knowing
what we
> build how. I can't really see this scaling.
>
I /believe/ the idea is that, like gn, there are folks maintaining these
build systems out of tree anyway - and having them in tree makes it easier
to coordinate that effort, with the express intent of not burdening the
general community with their upkeep (like gn currently - the idea is that
there's no burden on developers to update gn build files (& consequently
bazel build files)).

So far the gn build inclusion seems to have gone OK, I think? So maybe the
Bazel thing would be similar?

Sounds like the work is being done out of tree anyway, but having it
in-tree makes it a bit easier to coordinate interested parties, while not
adversely affecting unrelated parties, I think?

Though I'm not sure what the tradeoff/cost of this is compared to having a
separate project holding the build files, with LLVM as a git submodule. Not
knowing a lot about it, that /sounds/ like it gets most of the benefits/not
sure what the costs are?

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

On Thu, 29 Oct 2020 at 19:16, David Blaikie <dblaikie at gmail.com> wrote:
> I /believe/ the idea is that, like gn, there are folks maintaining these
> build systems out of tree anyway - and having them in tree makes it easier
> to coordinate that effort, with the express intent of not burdening the
> general community with their upkeep (like gn currently - the idea is that
> there's no burden on developers to update gn build files (&
consequently
> bazel build files)).
>
Perhaps the initial assumption about my concerns weren't well articulated.

I get that those files would be "additional" and other developers
won't
need to care much about them.

But what happens when people join the project with experience in Bazel and,
instead of building pure LLVM with CMake, they start using Bazel for
everything, just because they're used to it?

Bazel is big enough (at least inside Google) that the probability of that
happening is not trivial.

What if they create sub-projects that can only build with Bazel? Do we
refuse inclusion? But don't we have Bazel files already?

One big example is Android. They used to build LLVM in a very different
way, and the inclusion of run-time library files was completely different.
So different it was not possible to merge some changes they had (128 bit
maths IIRC) because of the amount of work required.

My point is that adding another build system will not necessarily improve
the chances of external people contributing to LLVM if they use those build
systems. It may very well *reduce* those chances.

Once we get to the point where Bazel support is "complete" enough, and
enough other projects that use LLVM use Bazel (I assume many internal
Google projects), the problem I describe above is bound to happen sooner or
later.

Personally, I'm happy to ignore Bazel and continue using CMake. But I just
wanted to make clear that in the past, using a different build system did
not increase the chances of contribution, so that's not a given in this
case either.

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