[LLVMdev] Transitioning build to cmake

[Charles Davis]

On Jul 25, 2013, at 10:21 AM, Jeremy Huddleston Sequoia wrote:

> 
> On Jul 24, 2013, at 14:18, Charles Davis <cdavis5x at gmail.com> wrote:
> 
>> 
>> On Jul 24, 2013, at 11:11 AM, Jeremy Huddleston Sequoia wrote:
>> 
>>> I recently took a stab at changing the MacPorts llvm-3.4 port from the configure-based build system to the cmake-based build system.
>>> 
>>> There are a couple of issues that I still haven't been able to work out yet and would like to know if these are just configuration issues on my side or bugs I should file at bugs.llvm.org:
>>> 
>>> 
>> tl;dr: LLVM CMake support is primarily designed for Windows/Visual Studio (especially in LLVM proper) and Linux (especially in compiler-rt), and needs lots of work to work well on Mac OS X or anywhere else. In particular, it is missing many features that are present in the autotools build. (Though, as the CMake proponents 'round here are quick to point out, the autotools system is itself missing some features that are present in CMake.)
> 
> The main reason for this was because it looked like autoconf was the second rate citizen:
>  1) only cmake supported building building the ubsan runtime for a while: http://llvm.org/bugs/show_bug.cgi?id=14341
>  2) some guides only talk about building with cmake (eg http://clang.llvm.org/docs/HowToSetupToolingForLLVM.html)
>  3) etc...
> 
> If 2-systems is the long term goal, then I'll stick with what works (but still file bugs if cmake folks want to track them).  If autoconf is going away at some point, I'd prefer to make the transition while we still have the fallback rather than have a period without it being available.
About the only thing I can gather that we've been able to agree on is that we do want to get rid of "autohell" (as some people around here like to call it :) at some point. In fact, AFAICT we're just keeping it around because some internal Apple build processes (cf. utils/buildit) still need it. Most people around here just use CMake now--especially because then, they can use Ninja to build LLVM--but I seem to recall (and a lot of people seem to have forgotten) Daniel Dunbar talking about replacing both autoconf and CMake with some custom build system that he was going to write in Python; the LLVMBuild.txt stuff was supposed to be the first phase of that. (Then a bunch of people, mostly from *BSD, objected because they didn't want Python as a build-time dependency, even though it already is now. They seem to be doing fine with LLVM despite that.) I also remember Daniel saying that he didn't really like CMake, not least because (at least, at the time he said it) its Xcode support sucked horribly; but at this point, I'm not sure he's ever going to get around to finishing this new build system of his. When push finally comes to shove, we'll probably end up with a CMake-based build system (unless Daniel or someone else pipes up in the meantime about it).
> 
>> ...
> 
>> The CMake support in compiler-rt evolved in a completely different direction from the Makefiles; it was primarily designed originally, IIRC, to support building asan (and later, the other sanitizers), and mostly on Linux at that. Other platforms and configurations were an afterthought. It needs serious work--in particular, the runtime libraries are built with the host compiler (not usually a problem, unless you're building a cross compiler), and (as you've probably noticed by now) it doesn't make fat archives. Patches welcome if you can speak CMake ;).
> 
> Ok.  Unfortunately, I speak m4 way better than cmake.  I've used it a few times, but I don't have much experience with it.
Unfortunately, I don't have many CPU cycles of my own to devote to fixing this (or else, I might have fixed this already). @LLVMdev: any volunteers?
> 
>>> ...
>> Well that's odd. I have CMake from trunk installed, and I was able to use it to build a very simple project with one C source universal. I was also able to build CMake itself universal. There's no bug in CMake--at least, not anymore. There might, however, be a bug in LLVM's build system that's causing this.
> 
> Ok, I'll try to figure this one out when I get some cycles.  I can probably trace where that goes wrong.  FWIW, I have cmake 2.8.10.2.
I tried v2.8.10.2 on this really small test project that I've attached (the same one I used to verify that CMake HEAD works), and it builds fat just fine. So yeah, there's almost definitely a problem with LLVM CMake and universal builds. Or, maybe there's a local problem with your CMake. (Not likely, but still...) Try building the attached (after un-tar'ing) like so:

 $ cd test.cm
 $ cmake -DCMAKE_OSX_ARCHITECTURES="i386;x86_64" -G"Unix Makefiles"
 $ make

and then you can run lipo -info on the "test" file that should've been built. It should report that there are two architectures in the file, i386 and x86_64.
> 
> Thanks for your responses,
No problem.

Chip

> Jeremy
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.tar.bz2
Type: application/x-bzip2
Size: 542 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130725/9bd45459/attachment.bin>