I'm a fairly new maintainer of Gentoo packages for LLVM and clang. I'm
trying to improve the way LLVM is built on Gentoo, and that's why I'm
wondering which of the build systems of LLVM is supported better.
As far as I'm aware, LLVM can be currently built using one of the two
build systems:
- one built on top of autoconf with custom Makefiles,
- the other one built on top of cmake with custom cmake modules.
My attempts at both build systems has shown that they both offer a bit
different build and install layouts, sets of features, bugs
and limitations.
Therefore I'd like to ask: which of the two build systems should I
focus on? Which one should I submit patches to? Which one should I
expect to be supported by external software?
So far, we've been using autoconf to build LLVM. However, this means
that we're unable to build some projects that rely on LLVM CMake
modules being installed. It also has semi-random shared library
naming which means that most of the external software doesn't support
linking to it, and instead links to the static libraries.
CMake on the other hand lacks support for udis86 code and OCaml
bindings, with the latter explicitly requested by our users. I recall
it also having unexpected test failures but that may have changed
since I last tried it. While it supports building llvm & clang
separately, it still pokes llvm build dirs (even if they don't exist
anymore) and tries to write files in there.
Both build systems lack proper SONAME versioning, though it's easier to
hack in into CMake.
That's a short summary of the issues I've faced. I'd like to work on
fixing them but I'd like to know which build system I should focus on
fixing.
Going forward, I believe CMake is the preferred build system. Eric Christopher floated the idea of jettisoning autoconf altogether, but maybe that’s just because he has the dubious honor of maintaining the autoconf system. http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-May/062351.html
As you pointed out, the CMake build doesn’t quite have feature parity with the autoconf build system. We have a tracking bug for it: http://llvm.org/bugs/show_bug.cgi?id=15732
Going forward, I believe CMake is the preferred build system. Eric
Christopher floated the idea of jettisoning autoconf altogether, but maybe
that's just because he has the dubious honor of maintaining the autoconf
system. http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-May/062351.html
While I generally prefer autotools over cmake as more consistent
and having better design, I am all for it. Most of autoconf's
advantages are lost when custom Makefiles are used instead of automake,
and having two build systems always end up causing trouble
and confusion.
I'm aware of that bug. However, I haven't seen much activity on fixing
the bugs. I'll start working on providing patches for at least some of
the issues.
Well, the most important thing right now would be to disable split
static libraries and force shared linking for everything. Sadly, that's
nowhere near to easy to do with a custom build system.
Additionally, I'd love to see those shared libs have sane SONAMEs.
Currently only the custom libLLVM-3.5svn.so has pseudo-name but not
many projects actually use that at all...
> Going forward, I believe CMake is the preferred build system. Eric
> Christopher floated the idea of jettisoning autoconf altogether, but
maybe
> that's just because he has the dubious honor of maintaining the autoconf
> system.
> http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-May/062351.html
While I generally prefer autotools over cmake as more consistent
and having better design, I am all for it. Most of autoconf's
advantages are lost when custom Makefiles are used instead of automake,
and having two build systems always end up causing trouble
and confusion.
I'm aware of that bug. However, I haven't seen much activity on fixing
the bugs. I'll start working on providing patches for at least some of
the issues.
I suspect that this is because almost all of the LLVM developers are mostly
preoccupied with the code rather than the build system (which they managed
to coerce into working for their purposes). They (this includes myself)
just have no impetus for doing this since it "works well enough for their
use case".
Any interaction with someone such as yourself---whose perspective is
primarily focused on the build system---is a great opportunity for seeing
what needs to be done and ratcheting up the quality of our build system and
our integration with packaging and other software. And I'm sure the hint of
incoming patches is making everyone's mouth water!
