[RFC] Progress report on CMake build system's ability to replace autoconf

Project Infrastructure LLVM Dev List Archives
#1

So, we’ve had this conversation a few times, and I wanted to coalate a status report for all the interested parties.

Here's the outstanding work and my (not necissarily correct) view of the status and importance of each one:

* Bug 12157 - llvmconfig.cmake.in make cmake installations not relocatable
  - There are patches on the bug that we should review, test, and land

* Bug 14109 - CMake build for compiler-rt should use just-built clang
  - Still waiting for patches, I don't think this is a blocker

* Bug 15493 - No option to build shared libLLVM-version.so in CMake
  - Patches out for review http://reviews.llvm.org/D6157

* Bug 18496 - [cmake] .S assembly files not compiled by cmake in libclang_rt.ARCH
  - Unclear if this is still a problem

* Bug 18722 - Option to use CMake with libc++ to compile clang
  - I think this is done by passing -DLLVM_ENABLE_LIBCXX=On

* Bug 19462 - Use the INSTALL(EXPORT ...) to export CMake definitions
  - I believe this is all done. I've never managed to get the import part of this to work, but the export files are generated

* Bug 19875 - libraries and executables need different rpaths
  - Still outstanding, I don't think this is a blocker.

* Bug 21560 - Add support to cmake for using installed versions of LLVM and Clang
  - Takumi commented that this works.

* Bug 21561 - Update release scripts to use CMake
  - Still outstanding and blocking removal of autoconf

* Bug 21562 - Add a CMake equivalent for make/platform/clang_darwin.mk in compiler_rt
  - From discussions on llvm-dev and IRC the proper fix for this is a cross-compiling approach for compiler_rt builds, and this is a blocker.

* Bug 21568 - Cannot add rpath
  - It looks like this is not a blocker because it can be done, but is unwieldy. I think this may be made a lot easier with help from the CMake developers.

* Bug 21569 - Can't `make install prefix=/tmp/llvm' with CMake.
  - I think this is a fundamental difference between CMake and autoconf, and people just need to get used to the difference

* Bug 21570 - Cannot set default configuration options for CMake
  - I think you can do this in CMake by creating a toolchain file and passing it in with CMAKE_TOOLCHAIN_FILE

Other issues not tracked by bugs:

* FreeBSD seemed to have problems with CMake identifying itself as amd64 causing x86_64 tests to fail
* Migrating buildbots
* CMake builds for libc++?

Thoughts? Anything missing?

-Chris

#2

So, we’ve had this conversation a few times, and I wanted to coalate a status report for all the interested parties.

Here’s the outstanding work and my (not necissarily correct) view of the status and importance of each one:

  • There are patches on the bug that we should review, test, and land
  • Bug 14109 - CMake build for compiler-rt should use just-built clang
  • Still waiting for patches, I don’t think this is a blocker
  • Bug 15493 - No option to build shared libLLVM-version.so in CMake
  • Bug 18496 - [cmake] .S assembly files not compiled by cmake in libclang_rt.ARCH
  • Unclear if this is still a problem
  • Bug 18722 - Option to use CMake with libc++ to compile clang
  • I think this is done by passing -DLLVM_ENABLE_LIBCXX=On
  • Bug 19462 - Use the INSTALL(EXPORT …) to export CMake definitions
  • I believe this is all done. I’ve never managed to get the import part of this to work, but the export files are generated
  • Bug 19875 - libraries and executables need different rpaths
  • Still outstanding, I don’t think this is a blocker.
  • Bug 21560 - Add support to cmake for using installed versions of LLVM and Clang
  • Takumi commented that this works.
  • Bug 21561 - Update release scripts to use CMake
  • Still outstanding and blocking removal of autoconf
  • Bug 21562 - Add a CMake equivalent for make/platform/clang_darwin.mk in compiler_rt
  • From discussions on llvm-dev and IRC the proper fix for this is a cross-compiling approach for compiler_rt builds, and this is a blocker.
  • Bug 21568 - Cannot add rpath
  • It looks like this is not a blocker because it can be done, but is unwieldy. I think this may be made a lot easier with help from the CMake developers.
  • Bug 21569 - Can’t `make install prefix=/tmp/llvm’ with CMake.
  • I think this is a fundamental difference between CMake and autoconf, and people just need to get used to the difference
  • Bug 21570 - Cannot set default configuration options for CMake
  • I think you can do this in CMake by creating a toolchain file and passing it in with CMAKE_TOOLCHAIN_FILE

Other issues not tracked by bugs:

  • FreeBSD seemed to have problems with CMake identifying itself as amd64 causing x86_64 tests to fail
  • Migrating buildbots
  • CMake builds for libc++?

Thoughts? Anything missing?

Thanks for the update Chris, one thing missing would be a quick cheat sheet transition guide for users etc to do “the things that they used to do”. Mostly something for the website under the developer documentation etc.

-eric

#3

Can you elaborate... what do you mean by this? AFAIK this already works.

Jon

#4

* Migrating buildbots

Most ARM/AArch64 bots are now running CMake. Only the test-suite is
not, but this is on my todo list for this month.

There are changes in progress to make it work on Windows, so there
should be no reason why it won't work with other arches / OSs.

* CMake builds for libc++?

libc++ already works with CMake, though I'm going to add it to the
CMake ClangBuilder, so that we can run it inside the build and
test-suite, but that's after merging LNT into the ClangBuilder. Since
it already works with CMake on its own, I think it's a lower priority.

cheers,
--renato

#5

Other issues not tracked by bugs:

* CMake builds for libc++?

Can you elaborate... what do you mean by this? AFAIK this already works.

Duncan made a comment on IRC about being libc++, but I’m not aware of what the specific issues were (hence the ?).

-Chris

#6

+kledzik and bogner, who looked into this last.

I don't remember quite what the issue is; perhaps Nick or Justin knows. I
remember the repro though:

1. Complete a CMake build of clang+libcxx+compiler-rt.
2. Add DYLD_LIBRARY_PATH=path/to/lib to the environment (so that ld64 finds
    the just-built libLTO.dylib).
3. Everything, including `/bin/ls` IIRC, crashes, since the just-built
    libcxx.dylib doesn't "work".

I work around this by not checking out libcxx in my CMake source trees (at
least, not when I'm using LTO).

#7

Other issues not tracked by bugs:

* CMake builds for libc++?

Can you elaborate... what do you mean by this? AFAIK this already works.

Duncan made a comment on IRC about being libc++, but I’m not aware of what the specific issues were (hence the ?).

-Chris

+kledzik and bogner, who looked into this last.

Duncan was concerned about libc++ on darwin.

The problem was/is that the shipping Apple libc++.dylib did not use CMake (or the previous buildit script). It used its own Xcode project which passed a bunch of special linker flags. Building libc++ for darwin without the special flags produced a dylib that only partially worked.

I have not recently tried to build libc++ for darwin from the LLVM repository. So, I don’t know if anyone has updated CMake files for libcxx to build something that works on darwin.

-Nick

#8

Other issues not tracked by bugs:

* CMake builds for libc++?

Can you elaborate... what do you mean by this? AFAIK this already works.

Duncan made a comment on IRC about being libc++, but I’m not aware of what the specific issues were (hence the ?).

-Chris

+kledzik and bogner, who looked into this last.

Duncan was concerned about libc++ on darwin.

The problem was/is that the shipping Apple libc++.dylib did not use CMake (or the previous buildit script). It used its own Xcode project which passed a bunch of special linker flags. Building libc++ for darwin without the special flags produced a dylib that only partially worked.

I have not recently tried to build libc++ for darwin from the LLVM repository. So, I don’t know if anyone has updated CMake files for libcxx to build something that works on darwin.

-Nick

Nick,
        David Fang's packaging of the llvm 3.5.1 release for the fink
project uses a cmake build of libc++ (as did the prior llvm 3.4.2
packaging). The libc++ changes are at…

http://fink.cvs.sourceforge.net/viewvc/fink/dists/10.7/stable/main/finkinfo/languages/llvm35-libcxx.patch

but has some changes for support ppc builds and earlier darwin
releases mixed in the patch.
                Jack

#9

Hi,
   About my libc++ patches: the bits relevant to building are isolated to CMakeLists.txt and lib/CMakeLists.txt, and as Jack said they mostly concern support for OS X pre-10.7: adjusted header checks, link options, etc. Though not the biggest fan of cmake, I can testify that it "works". During bootstraps, I only build libc++ separately from the LLVM+clang build, as stages 1.5 and 2.5 (which converge).

Fang

Other issues not tracked by bugs:

* CMake builds for libc++?

Can you elaborate... what do you mean by this? AFAIK this already works.

Duncan made a comment on IRC about being libc++, but Iÿÿm not aware of what the specific issues were (hence the ?).

-Chris

+kledzik and bogner, who looked into this last.

Duncan was concerned about libc++ on darwin.

The problem was/is that the shipping Apple libc++.dylib did not use CMake (or the previous buildit script). It used its own Xcode project which passed a bunch of special linker flags. Building libc++ for darwin without the special flags produced a dylib that only partially worked.

I have not recently tried to build libc++ for darwin from the LLVM repository. So, I donÿÿt know if anyone has updated CMake files for libcxx to build something that works on darwin.

-Nick

Nick,
         David Fang's packaging of the llvm 3.5.1 release for the fink
project uses a cmake build of libc++ (as did the prior llvm 3.4.2
packaging). The libc++ changes are atÿÿ

http://fink.cvs.sourceforge.net/viewvc/fink/dists/10.7/stable/main/finkinfo/languages/llvm35-libcxx.patch

but has some changes for support ppc builds and earlier darwin
releases mixed in the patch.
                 Jack

#10

We'll need to update the script used for building releases
(utils/release/test-release.sh) to use CMake. Once this is done, we
can switch the release to CMake, which would be a nice milestone :slight_smile:

- Hans

#11

I believe that was on my list as "Bug 21561 - Update release scripts to use CMake”

-Chris

#12

Here's the outstanding work and my (not necissarily correct) view of the status and importance of each one:

* Bug 14109 - CMake build for compiler-rt should use just-built clang
   - Still waiting for patches, I don't think this is a blocker

We consider this one a blocker. We shouldn't be assuming that we have available a compiler capable of doing build->target or host->target, other than the host->target one that is the just-built clang.

I've heard discussions in the past about this restriction of cmake, but I don't remember the details. Is this something where we could up the minimum required version of cmake to get features we'd need to use in the CMakeLists.txt's? Is there a way to work around it?

Having a bootstrap flag for the cmake configure would make it less of a blocker, though I'd still prefer not to have to boostrap every build. IIRC, Chandler has some notes on the right way to pull that off.

Cheers,

Jon

#13

+alexey

Here's the outstanding work and my (not necissarily correct) view of
the status and importance of each one:

* Bug 14109 - CMake build for compiler-rt should use just-built clang
   - Still waiting for patches, I don't think this is a blocker

I Just discovered LLVM_BUILD_EXTERNAL_COMPILER_RT implemented by Alexey in r202367 - [CMake] Teach build system to build/test compiler-rt with a just-built Clang
This causes compiler-rt to be built with the just-built clang. For my purposes, this unblocks dropping autoconf (aside from some internal hassles with getting cmake built, but that's on me to deal with).

I think it would be better if we built that way by default. What blocks flipping the switch so that the "build with the host compiler" behavior becomes opt-in? I see a note that this flag blocks using the Ninja generator: http://www.cmake.org/Bug/view.php?id=14771 Can that be worked around? Is there anything else?

Cheers,

Jon

#14

+Ed Maste, who maintains FreeBSD’s LLDB and probably does not check this very often. I know (or at least am pretty sure) that they are using autoconf over there, so he may be aware of other issues.

#15

Ed,

Just to be clarify the timeline for this is somewhere between 6 months and never. Don’t look at this as impending, but also don’t ignore it.

We have a sizable list of outstanding issues, and some of them are quite substantial (like compiler-rt). Without a concerted effort from the community this is unlikely to happen.

-Chris

#16

+alexey

Here's the outstanding work and my (not necissarily correct) view of
the status and importance of each one:

* Bug 14109 - CMake build for compiler-rt should use just-built clang
   - Still waiting for patches, I don't think this is a blocker

I Just discovered LLVM_BUILD_EXTERNAL_COMPILER_RT implemented by Alexey
in https://www.mail-archive.com/cfe-commits@cs.uiuc.edu/msg91501.html
This causes compiler-rt to be built with the just-built clang. For my
purposes, this unblocks dropping autoconf (aside from some internal hassles
with getting cmake built, but that's on me to deal with).

Right, I believe we should revisit this mode and eventually make
LLVM_BUILD_EXTERNAL_COMPILER_RT the only available option (for now it's not
the default and only runs on our buildbot). I'll see if we can workaround
the Ninja problem somehow. I also believe we should do a major rewrite of
the way this mode (and CMake build for compiler-rt) is implemented. Instead
of having a single compiler-rt build tree that would guess which
architectures the host compiler can target, and build runtimes for all of
them (which leads to "foreach(arch ${SANITIZER_COMMON_SUPPORTED_ARCH})" all
around), we might instead create one build tree for each target we support,
and pass host compiler (just-built Clang) and flags to target that
architecture (we may cross-compile) down to that build tree. That would
drastically simplify CMake build rules. I hope I will be able to experiment
with that soon.

#17

We generally don't use the autoconf build here. All of my development
against the upstream repository is done with cmake+ninja.

We also have a copy of LLVM+Clang+LLDB in the FreeBSD base system.
That one uses yet another build system - a set of bespoke BSD make
Makefiles. For example, liblldb's Makefile is here:
https://svnweb.freebsd.org/base/head/lib/clang/liblldb/Makefile In the
case of LLDB I created these mainly by using sed on the CMakeLists.txt
files.

It looks like the FreeBSD LLDB buildbot is using autoconf, but that
should be easily changed.

#18

Just for the record, as far as NetBSD is concerned, LLDB without
autoconf is a non-issue. autoconf is only relevant for the
bootstrapping, so code outside llvm, clang and maybe lld is perfectly
acceptable as cmake-only.

Joerg

#19

So, we’ve had this conversation a few times, and I wanted to coalate a
status report for all the interested parties.

Here's the outstanding work and my (not necissarily correct) view of the
status and importance of each one:

* Bug 12157 - llvmconfig.cmake.in make cmake installations not relocatable
  - There are patches on the bug that we should review, test, and land

* Bug 14109 - CMake build for compiler-rt should use just-built clang
  - Still waiting for patches, I don't think this is a blocker

* Bug 15493 - No option to build shared libLLVM-version.so in CMake
  - Patches out for review http://reviews.llvm.org/D6157

* Bug 18496 - [cmake] .S assembly files not compiled by cmake in
libclang_rt.ARCH
  - Unclear if this is still a problem

* Bug 18722 - Option to use CMake with libc++ to compile clang
  - I think this is done by passing -DLLVM_ENABLE_LIBCXX=On

* Bug 19462 - Use the INSTALL(EXPORT ...) to export CMake definitions
  - I believe this is all done. I've never managed to get the import part
of this to work, but the export files are generated

* Bug 19875 - libraries and executables need different rpaths
  - Still outstanding, I don't think this is a blocker.

* Bug 21560 - Add support to cmake for using installed versions of LLVM
and Clang
  - Takumi commented that this works.

* Bug 21561 - Update release scripts to use CMake
  - Still outstanding and blocking removal of autoconf

* Bug 21562 - Add a CMake equivalent for make/platform/clang_darwin.mk in
compiler_rt
  - From discussions on llvm-dev and IRC the proper fix for this is a
cross-compiling approach for compiler_rt builds, and this is a blocker.

* Bug 21568 - Cannot add rpath
  - It looks like this is not a blocker because it can be done, but is
unwieldy. I think this may be made a lot easier with help from the CMake
developers.

* Bug 21569 - Can't `make install prefix=/tmp/llvm' with CMake.
  - I think this is a fundamental difference between CMake and autoconf,
and people just need to get used to the difference

* Bug 21570 - Cannot set default configuration options for CMake
  - I think you can do this in CMake by creating a toolchain file and
passing it in with CMAKE_TOOLCHAIN_FILE

Other issues not tracked by bugs:

* FreeBSD seemed to have problems with CMake identifying itself as amd64
causing x86_64 tests to fail
* Migrating buildbots
* CMake builds for libc++?

Thoughts? Anything missing?

One more thing: we should probably update "Getting Started" pages (
http://clang.llvm.org/get_started.html,
http://llvm.org/docs/GettingStarted.html#getting-started-quickly-a-summary)
to
refer to CMake as the "recommended" way to build LLVM, and to autotools as
"works for now".

#20

Seems reasonable.

-eric