<div dir="ltr">Thanks for the responses everyone! Much appreciated!<div><br></div><div>I have given this some thought and the better solution I could come up with is to build LLVM with the CMake build system inside a fresh Docker container, upload the binaries to cloud storage, and use these binaries to build up toolchains inside Bazel. Does this make sense?</div><div><br></div><div>This removes the need to change LLVM, introduce new dependencies, etc.</div><div><br></div><div>Also, if anyone of you have more information of how to build LLVM inside a Docker container for Linux, MacOS, and Windows, I would really like to know more about it.</div><div><br></div><div>The reason I want to do this is because I am developing a system emulator, kind of like Qemu, but for really old machines like the Amiga and Commodore 64, and I want to build and release binaries all from within Bazel (Bazel having native cross-compilation, and an awesome test framework).</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Aug 13, 2019 at 9:09 AM Kristina Brooks <<a href="mailto:notstina@gmail.com">notstina@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I agree, IMHO Bazel support in-tree would likely not be amazingly<br>
useful as it doesn't offer a lot in relation to local builds and is<br>
pretty large (while GN and Ninja binaries can be compiled and<br>
statically linked pretty easily). To add to that, while it makes sense<br>
to integrate LLVM builds into large repositories that use a different<br>
build system (ie. TF), especially when support for multiple languages<br>
is desired, the upstream LLVM repositories are pretty much almost<br>
entirely C/C++. So I don't believe having it upstream would bring much<br>
overall benefit - its scope is simply too broad.<br>
<br>
Also as far as GN goes, I think it was universally agreed on that it<br>
wasn't a replacement for CMake but rather a second buildsystem, since<br>
it does bring considerable performance benefits when it comes to<br>
regenerating the Ninja buildfiles to those that see it as a<br>
bottleneck, as well as it being relatively independent and with far<br>
less extra baggage (unlike a typical CMake install), only requiring<br>
Ninja and a host toolchain to work. In a similar fashion it has<br>
support for compiler wrappers (ie. through "command_launcher")<br>
allowing things like gomacc/RBE to be used for distributed<br>
compilation.<br>
<br>
Thank you.<br>
<br>
On Mon, Aug 12, 2019 at 10:23 PM Chris Bieneman via llvm-dev<br>
<<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
><br>
> Hi Wynand,<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> 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?<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> -Chris<br>
><br>
><br>
> On Aug 8, 2019, at 4:24 PM, Mehdi AMINI via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
><br>
> Hi,<br>
><br>
> On Thu, Aug 8, 2019 at 4:15 PM Wynand Pieterse via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
>><br>
>> Hi all, trust all is well!<br>
>><br>
>> 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.<br>
><br>
><br>
> 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:<br>
> 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.<br>
> 2) It is memory heavy (maybe related to the previous point...): it consumes multiple GB by itself when building LLVM.<br>
> 3) There are other solutions to have remote build execution and caching, for instance the Chrome 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).<br>
> 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?<br>
><br>
>><br>
>> 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.<br>
><br>
><br>
> 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 (it is probably not complete, but maybe a good way to get started).<br>
><br>
> Best,<br>
><br>
> --<br>
> Mehdi<br>
><br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
><br>
><br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>