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>
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 The big ticket items are: OCaml bindings: http://llvm.org/bugs/show_bug.cgi?id=15325 Building a big libLLVM.so DSO: http://llvm.org/bugs/show_bug.cgi?id=15493 Building compiler-rt with the just-built compiler: http://llvm.org/bugs/show_bug.cgi?id=14109 On Thu, Dec 26, 2013 at 5:19 AM, Michał Górny <mgorny at gentoo.org> wrote:> 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 > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131226/a3a402ed/attachment.html>
Dnia 2013-12-26, o godz. 09:29:39 Reid Kleckner <rnk at google.com> napisał(a):> 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.htmlWhile 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.> 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=15732I'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. -- 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/d45af12f/attachment.sig>
On 26/12/2013 14:19, Michał Górny wrote:> 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. >From the Debian/Ubuntu perspective, I am using the autotools build system.As mentioned before, the bug 15732 tracks it. I might be switching to cmake once it is fixed but until then. I will be using autotools. I will be happy to help you if you need anything. Sylvestre
Dnia 2013-12-27, o godz. 17:41:01 Sylvestre Ledru <sylvestre at debian.org> napisał(a):> On 26/12/2013 14:19, Michał Górny wrote: > > 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. > From the Debian/Ubuntu perspective, I am using the autotools build system. > As mentioned before, the bug 15732 tracks it. I might be switching to > cmake once it is fixed but until then. I will be using autotools. > > I will be happy to help you if you need anything.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... -- 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/20131227/6ddd91d0/attachment.sig>