[LLVMdev] State of build system support in LLVM

[Michał Górny]

Hello, all.

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.

-- 
Best regards,
Michał Górny
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 966 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131226/7f6500ab/attachment.sig>