[RFC] Late May Update: Progress report on CMake build system's ability to replace autoconf

Hi all,

Time for another update on the status of the CMake build system.

Completed:
* Bug 18496 - [cmake] .S assembly files not compiled by cmake in libclang_rt.ARCH
* Bug 22725 - lldb build with cmake fails with "Program error: Invalid parameters entered, -h for help. "
* Update GettingStarted to prefer CMake

Still Outstanding:

* Bug 14109 - CMake build for compiler-rt should use just-built clang
- No Update: Still some small issues to resolve.

* Bug 19462 - Use the INSTALL(EXPORT ...) to export CMake definitions
- I commented in the review for this today (http://reviews.llvm.org/D7623). I think the patches I have are good to land, but Stephen Kelly made some other suggestions in the bug we should consider separately.

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

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

* Bug 21562 - Add a CMake equivalent for make/platform/clang_darwin.mk in compiler_rt
- I've looked at this a bit on and off. It is unfortunately a hard problem. I think it would be easier if CMake had better support for setting clang's sysroot and arch flags. To that end I've filed a bug against CMake (http://www.cmake.org/Bug/view.php?id=15591).

* Bug 21568 - Cannot add rpath
- No Update: Not a blocker.

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
* We need to make sure libc++ works properly on Darwin
* Put together a “cheat sheet” document for transitioning
- If you have an autoconf workflow you’d like to see in the cheat sheet please send your commands my way and I‘ll assemble the cheat sheet.

If there is anything I’m missing please let me know. Thanks,

Thanks,
-Chris

Probably not a blocker for replacing autoconf, while at it:
Bug 23468 - LLVM_OPTIMIZED_TABLEGEN does not work with Visual Studio.
It makes the tablegenning really slow.

Probably not a blocker for replacing autoconf, while at it:
Bug 23468 - LLVM_OPTIMIZED_TABLEGEN does not work with Visual Studio.
It makes the tablegenning really slow.

This is actually a feature of the CMake build system that the autoconf one doesn’t have, so this is not related to replacing autoconf.

That said, I’ll try to address this soon.

-Chris

Thanks!

I sent out a patch for review.

http://reviews.llvm.org/D10102

-Chris

Do they really allways put them into Release/bin or rather $/bin?

Both Release and $CONFIG tblgen are built but the Release one is always used. At least with Visual C++ the Release tblgen is much faster than the Debug one.

That it’s faster is no surprise. Is the Release tblgen even built when you build in Debug mode? Otherwise this introduces the need to build Release before Debug.

Yes, that’s the idea, when you -DLLVM_OPTIMIZED_TABLEGEN=ON tblgen is built in Release in addition to whatever /property:Configuration= is.

To answer Johannes’ questions:

Yes. When generating multi-configuration build files (Xcode, Visual Studio, Eclipse…) the binaries are always built to $CMAKE_BINARY_DIR/$CMAKE_BUILD_TYPE/bin/…

For multi-configuration generators I hard-code the type as Release because the whole point of this patch is to use the Release tablegen.

That is exactly what the LLVM_OPTIMIZED_TABLEGEN flag does. It is kinda hacky, but it can dramatically reduce build times. There is probably a way to make this work better for multi-config builds, but the general idea is that when you enable the flag CMake generates two configured build directories - one for what you wanted to use, and one for CMake to use to generate an optimized tablegen. It then hooks up the dependencies so that the optimized tablegen is used in place of an unoptimized one.

The speedup can be significant. >From my experience I see the best results using the Ninja generator, but once I land this last patch it will, hopefully, work with all generators.

-Chris

It seems the fix for Bug 19462 causes my stand-alone build of Clang to die with

CMake Error at CMakeLists.txt:528 (install):
  install EXPORT given no DESTINATION!

Any pointers?

Takumi fixed that issue with r238628.

Thanks,
-Chris

Chris Bieneman wrote:

Takumi fixed that issue with r238628.

For reference, this addressed the concern I raised in the bug report:

https://llvm.org/bugs/show_bug.cgi?id=19462

"I don't know if the LLVM_INSTALL_PACKAGE_DIR symbol is suitable for
downstreams to use"

Thanks,

Hi,

I recently discovered that CMake has difficulty handling multilibs for Mips. This isn't a blocker at the moment since we only do 32-bit releases on llvm.org but will be a problem when we start 64-bit releases.

There's a bit more detail at: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=785401

I’ve been trying, and thus far failing, to get the test suite up and running against a CMake+ninja clang build. Filed https://llvm.org/bugs/show_bug.cgi?id=23746. Depending on what workarounds people know of or can come up with, that may or may not be a blocker.

-Jim

I've been successfully using LNT to run the test-suite based on CMake
builds. Sometimes have to symbolically link ld64 into build/bin
directory, but otherwise I just go for some variant of:

~/lnt-sandbox/bin/lnt runtest --verbose nt \
    --sandbox ~/lnt-sandbox/results \
    --test-suite ~/lnt-sandbox/test-suite \
    --test-externals ~/lnt-sandbox/test-suite-externals \
    --cc ~/llvm/build.rel/bin/clang \
    --cflag="-flto -O3 -stdlib=libstdc++" \
    --without-llvm \
    --simple \
    --small \
    -j 4

Tim.