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
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
