[LLVMdev] Transitioning build to cmake

[Jeremy Huddleston Sequoia]

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.

> ...

> 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.

>> ...
> 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.

>> 3) Shared library
>> 
>> The build fails if I try to build llvm using BUILD_SHARED_LIBS=ON ... the issue is that when the build tries to use the tools, dyld can't find libllvm-3.4svn.dylib because it's not yet installed.
> The CMake build obviously needs to be taught to set the install names to relative paths on Mac OS, like the autotools build does.

Yep ... probably because as you mentioned above, this was primarily for VisualStudio and Linux as clients.


Thanks for your responses,
Jeremy

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4136 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130725/78ff0f25/attachment.bin>