Since my last update we’ve landed patches for these issues:
* Bug 14200 - -fno-rtti not in cxxflags given by llvm-config
* Bug 23746 - test-suite lacks CMake support
* Bug 25059 - CMake libllvm.so.$MAJOR.$MINOR shared object name not compatible with ldconfig
On my last thread Jonathan Roelofs pointed out that there is a workaround for Bug 21568 (Cannot add rpath), so I’m making it non-blocking. Which leaves only Bug 23947, which I’m also going to move that to non-blocking because it only applies to building LLVM on MIPS64 hardware.
With those changes we have no issues left blocking deprecating autoconf. There are still some issues we should track and follow through on, but I think all major uses are covered and we can make CMake the only officially supported way to build LLVM.
My proposal at this point is that we should officially deprecate autoconf, and I would like to follow this process for removing it:
(1) Add a note to the release notes for 3.8, and a big warning at the end of the configure script telling people to use CMake
(2) Support autoconf with bug fixes only, no new features for 3.8
(3) After the 3.8 branch remove all the makefiles and have the configure script log a message to use CMake
(4) After the 3.9 branch remove the configure script completely
I’ve attached a patch that handles the first step. Please let me know if this sounds like a reasonable path for the community.
Also, a big “Thank You” to everyone who has contributed patches, reviewed patches, and helped out with this work over the last year. It has been a long road, but the end is in sight!
My proposal at this point is that we should officially deprecate autoconf, and I would like to follow this process for removing it:
Hi Chris,
+2 for this!
We have moved every ARM and AArch64 buildbot to CMake, and the 3.7
release was done using CMake. So now, I don't even know if autoconf
works any more.
(1) Add a note to the release notes for 3.8, and a big warning at the end of the configure script telling people to use CMake
(2) Support autoconf with bug fixes only, no new features for 3.8
(3) After the 3.8 branch remove all the makefiles and have the configure script log a message to use CMake
(4) After the 3.9 branch remove the configure script completely
During the 3.7 release, Dimitry reported that some components didn't
build on FreeBSD with cmake yet. Is that fixed now? I'd like to have
all binaries built with cmake for 3.8.
I think we're OK here. I've got llvm, clang, clang-tools-extra,
compiler-rt, lld, lldb, and openmp building from cmake in the FreeBSD
ports collection.
Also add a deprecation warning to the top of docs/BuildingLLVMWithAutotools.rst ( with .. warning::, which will make a big fancy box), and remove mention of autotools from docs/GettingStarted.rst
Just wanted to give an explicit agreement with your plan for deprecating autoconf. Looking forward to it. Thanks for the crazy amount of work this has required.
Which leaves only Bug 23947, which I’m also going to move that to non-blocking because it only applies to building LLVM on MIPS64 hardware.
+1 that this should be non-blocking and to the deprecation of autoconf in general. Just for the sake of correctness: PR23947 isn’t exactly about building on MIPS64 hardware. It’s really about building for a non-default multilib (in this case the 64-bit multilibs of a generally 32-bit linux distribution).
We still have several buildbots on autoconf at the moment but I’ll sort that out.
During the 3.7 release, Dimitry reported that some components didn't
build on FreeBSD with cmake yet. Is that fixed now? I'd like to have
all binaries built with cmake for 3.8.
I think we're OK here. I've got llvm, clang, clang-tools-extra,
compiler-rt, lld, lldb, and openmp building from cmake in the FreeBSD
ports collection.
While it will probably all build (I'm testing that again now), I don't
think all tests will succeed. Specifically in compiler-rt and some
other parts.
It would be very nice to be able to resolve all that before 3.8.0.
Hm, I spoke too soon. It bombs out fairly quickly with an error about
unwind.h (which we unfortunately *still* don't have in /usr/include, Ed
is working on that):
In file included from /home/dim/src/llvm/trunk/projects/libcxxabi/src/cxa_default_handlers.cpp:19:
/home/dim/src/llvm/trunk/projects/libcxxabi/src/cxa_exception.hpp:19:10: fatal error: 'unwind.h' file not found #include "unwind.h"
^
1 error generated.
But this is during the libcxxabi build. I don't think we have can build
libcxxabi at all on FreeBSD? Brooks or Ed, did you ever manage that?
