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

[David Blaikie via llvm-dev]

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>