[llvm-dev] [RFC] Late October Update: Progress report on CMake build system's ability to replace autoconf
Chris Bieneman via llvm-dev
llvm-dev at lists.llvm.org
Tue Oct 27 16:19:10 PDT 2015
> On Oct 27, 2015, at 4:10 PM, Andrew Wilkins <axwalk at gmail.com> wrote:
> On Wed, 28 Oct 2015 at 04:17 Chris Bieneman via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> Hi LLVMDev,
> There’s been a good bit of progress this month, and with the dev meeting later this week I thought I’d send out a second update. There are only two outstanding blocking issues that don’t have patches proposed, PR 21568 & PR 23947. I would greatly appreciate if someone who works on Mips would take a look at PR 23947.
> The following issues have been marked as fixed since the last update I sent out.
> * Bug 14109 - CMake build for compiler-rt should use just-built clang
> * Bug 24157 - CMake built shared library does not export all public symbols
> These issues are still outstanding. Classification of blocking vs non-blocking are my own opinions, please let me know if you disagree. All non-blocking issues are still serious bugs that need to be fixed.
> Blocking Issues:
> * Bug 14200 - -fno-rtti not in cxxflags given by llvm-config (Patches out for review http://reviews.llvm.org/D11849 <http://reviews.llvm.org/D11849>)
> * Bug 21568 - Cannot add rpath
> * Bug 23947 - CMake+Mips: find_library() doesn't work correctly when recursing 64-bit (both N32 and N64 ABI's) compiler on Debian Jessie
> * Bug 25059 - CMake libllvm.so.$MAJOR.$MINOR shared object name not compatible with ldconfig (Two conflicting approaches are proposed to fix this in http://reviews.llvm.org/D13841 <http://reviews.llvm.org/D13841> & http://reviews.llvm.org/D14040 <http://reviews.llvm.org/D14040>)
> Sorry Chris, I had not seen your proposal. A little more background on why I implemented such a complicated approach.
> Debian's current packaging tacks a ".1" on the end of the SONAME. I *think* this is necessary, but I'm not a Debian packaging expert; Sylvestre could confirm. Anyway, that .1 doesn't make sense for everyone (anyone else?), which is why it would be specified in an option.
Your patch and mine do very different things, and I’m not very picky about how this gets handled because I mostly care about Darwin. My patch reworks construction of the output file names so that they match autoconf (libLLVM-3.8.0svn.so as opposed to libLLVM.so.3.8.0svn). Your patches make the versions and library name configurable. Not sure if they both meet the same need.
I’m not really picky about how the problem is solved as long as it is solved.
> Non-Blocking Issues:
> * Bug 19875 - libraries and executables need different rpaths
> * Bug 22466 - cmake build should provide way to run tablegen with no arguments
> * Bug 23746 - test-suite lacks CMake support (Part 1 landed r251431, Part 2 approved patches http://reviews.llvm.org/D14061 <http://reviews.llvm.org/D14061>)
> * Bug 24919 - [autoconf -> cmake] libclang.a is not packaged in the Ubuntu x86_64 pre-built
> 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
> Thank you everyone who has helped out to get us this far. We're getting awfully close now!
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev