New clang/llvm ports

[Michael Feiri]

Am 28.10.2011 um 00:45 schrieb Jeremy Huddleston:

> In r86535, I added new ports for {clang,llvm}-{2.9,3.0,3.1}.  This will allow us to support multiple versions of llvm and clang in a similar fashion to how we currently support multiple versions of gcc.  Additionally, this will allow dependent projects to rely on a *specific* version of llvm.
> 
> Once everything is flushed out, we will obsolete the old ports and have them redirect to -2.9 (for clang and llvm) or -3.1 (for clang-devel and llvm-devel).
> 
> I want to create a port select group for llvm and clang, and I'm curious what we should do.  Should we create just clang and llvm groups, or should we also create a cc group which will let someone set ${prefix}/bin/cc and ${prefix}/bin/c++?


I see you followed the advice to create versioned ports and to realize this by installing into subdirectories in ${prefix}/libexec/. I just didnt expect you'd go ahead and commit that to the main repository immediately. Well, I'll add myself as a co-maintainer.

One thing you missed is link-time-optimization. I briefly mentioned libLTO in our private discussion: The ld64 linker can not find libLTO.dylib in a subdirectory in ${prefix}/libexec. Thus it can not support link-time-optimization. Luckily ld64 searches libLTO.dylib relative to its location, even if it is executed through a symlink (see ticket #29173 for reference). My plan is to create a symlink to ld64 in ${prefix}/libexec/llvm-${version}/bin/ and to redirect the relevant compilers to use ld64 through that symlink. This will enable link-time-optimization using the matching version of libLTO. And it should be far safer than requiring a specific setting of an llvm port group (or a hypothetical llvm_select tool) or relying on a mismatched libLTO. Compilers that ignore this will simply not have LTO support.

Regards, Michael