Hi Wynand,
My big concern is related to what Mehdi mentioned as #4. Bazel doesn't
really handle the configuration-management that CMake does, so adding Bazel
support would really mean supporting an extra build system with no path for it
to replace CMake. We're kinda already in that situation with gn, but gn is a
developer productivity tool and we don't consider changes that break gn to
be build-breaking.
Anyone who has been working on LLVM long enough will remember the headaches we
had as a community when we supported both CMake and autoconf as primary build
systems. Frequently changes would break one or the other build system, we had
lots of issues with autoconf versioning, and it was generally considered an
undue burden on the community to have more than one build system.
To justify adding a new build system I think one big question we would need to
answer is what does this get us that we *can't* get from CMake, and does
that justify the burden?
In your initial email you mentioned remote builds and caching. CMake supports
both of these things if the underlying generator does. For many releases, CMake
supports an option `CMAKE_<LANG>_COMPILER_LAUNCHER` which integrates with
caching tools like ccache, and distribution tools like distcc.
Personally I think the best path for a real solution to building LLVM with Bazel
would likely be for CMake to get support for generating Bazel build files. That
is a topic that has come up on the CMake developer mailing lists, but I
don't believe there has been any progress on it due to nobody actively
working on it.
-Chris
> On Aug 8, 2019, at 4:24 PM, Mehdi AMINI via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
>
> Hi,
>
> On Thu, Aug 8, 2019 at 4:15 PM Wynand Pieterse via llvm-dev <llvm-dev at
lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> Hi all, trust all is well!
>
> I was wondering if LLVM would have a Bazel integrated build in the future?
I can imagine the benefits this could bring, especially with regards to remote
builds and caching.
>
> There was a round-table at EuroLLVM on this topic. I couldn't
participate fully (I was writing my slides...) but I remember some key elements
that we not playing in favor of Bazel:
> 1) It is written in Java, and not widely available by default on every
platform. This is not a nice property to base a key piece of the requirement for
getting started with LLVM.
> 2) It is memory heavy (maybe related to the previous point...): it consumes
multiple GB by itself when building LLVM.
> 3) There are other solutions to have remote build execution and caching,
for instance the Chrome Goma Client
<https://chromium.googlesource.com/infra/goma/client> implements the same
protocol for remote execution as Bazel and (in theory at least) can integrate
well with `CMake` and `ninja` to build a project like LLVM (I am actually
playing with this these days).
> 4) While sandboxing and the declarative approach that Bazel is using is
nice, it isn't clear to me that Bazel provides the same ability that CMake
has to detect the environment and configure the build. The "regular"
LLVM build is likely easy to mimic with Bazel, but can you plumb all the knob
and make it work on every platform that LLVM support?
>
> I'm thinking of dumping the LLVM source-tree into my code-base and
experiment with building LLVM via Bazel. Will pull requests be accepted for
this? I won't mind contributing my changes back into the upstream.
>
> If you want to get started an play with it, the TensorFlow project builds
LLVM with Bazel. They maintain their own BUILD file for LLVM
<https://github.com/tensorflow/tensorflow/blob/master/third_party/llvm/llvm.autogenerated.BUILD>
(it is probably not complete, but maybe a good way to get started).
>
> Best,
>
> --
> Mehdi
>
> _______________________________________________
> 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/20190812/96b9ae31/attachment.html>