<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi Wynand,<div class=""><br class=""></div><div class="">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.<div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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?</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">-Chris</div><div class=""><div class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Aug 8, 2019, at 4:24 PM, Mehdi AMINI via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div dir="ltr" class="">Hi,</div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Aug 8, 2019 at 4:15 PM Wynand Pieterse via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr" class="">Hi all, trust all is well!<div class=""><br class=""></div><div class="">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.</div></div></blockquote><div class=""><br class=""></div><div class="">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:</div><div class="">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.</div><div class="">2) It is memory heavy (maybe related to the previous point...): it consumes multiple GB by itself when building LLVM.</div><div class="">3) There are other solutions to have remote build execution and caching, for instance the <a href="https://chromium.googlesource.com/infra/goma/client" class="">Chrome Goma Client</a> 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).</div><div class="">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?</div><div class=""> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr" class=""><div class="">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.</div></div></blockquote><div class=""></div><div class=""><br class=""></div><div class="">If you want to get started an play with it, the TensorFlow project builds LLVM with Bazel. They maintain their own <a href="https://github.com/tensorflow/tensorflow/blob/master/third_party/llvm/llvm.autogenerated.BUILD" class="">BUILD file for LLVM</a> (it is probably not complete, but maybe a good way to get started).</div><div class=""><br class=""></div><div class="">Best,</div><div class=""><br class=""></div><div class="">-- </div><div class="">Mehdi</div><div class=""><br class=""></div></div></div>
_______________________________________________<br class="">LLVM Developers mailing list<br class=""><a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a><br class="">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev<br class=""></div></blockquote></div><br class=""></div></div></div></body></html>