clang, llvm: don't use svn

[ryandesign (Ryan Carsten Schmidt)]

The descriptions of llvm-2.9, llvm-3.0, llvm-3.1 and llvm-3.2 say they are the "svn trunk version" but they're not anymore; they're all stable versions now.

The post-extract block of clang-2.9 runs:

system "cd ${worksrcpath}/projects && svn co -r ${compiler_rt_rev} http://llvm.org/svn/llvm-project/compiler-rt/trunk compiler-rt"

The post-extract block of clang-3.0 runs:

system "cd ${worksrcpath}/projects && svn co -r ${compiler_rt_rev} http://llvm.org/svn/llvm-project/compiler-rt/branches/release_30 compiler-rt"

The post-extract blocks of clang-3.0 and clang-3.1 run:

system "cd ${worksrcpath}/projects && svn co -r ${libcxx_rev} http://llvm.org/svn/llvm-project/libcxx/trunk libcxx"

And the post-extract block of clang-3.2 runs:

system "cd ${worksrcpath}/projects && svn co -r ${libcxx_rev} http://llvm.org/svn/llvm-project/libcxx/branches/release_32 libcxx"

Is it still necessary to check out additional code from svn now that these ports are stable versions? If so, an extract dependency on bin:svn:subversion should be declared, otherwise this will fail on Tiger when the user has not already installed the subversion port (because Tiger does not come with svn).

The post-destroot blocks of clang-2.9, clang-3.0, clang-3.1 and clang-3.2 run:

system "install_name_tool -change @executable_path/../lib/libLLVM-${llvm_version}svn.dylib ${sub_prefix}/lib/libLLVM-${llvm_version}svn.dylib ${destroot}${sub_prefix}/lib/libclang.dylib"

Should "svn" be in the name of this library since these are stable versions, not svn trunk versions?

[jeremyhu (Jeremy Huddleston Sequoia)]

Yes, we need to pull in that code from svn because it's not in a release tarball.

The first comments are addressed in r101047.

[jeremyhu (Jeremy Huddleston Sequoia)]

As for the second, that's handled in r101049. I didn't bump the revision because there should be no real consequence of this. That change was just for consistency and doesn't really affect what gets loaded (since the relative path should always resolve the same as the absolute path).