Opened 8 years ago

Closed 8 years ago

#37501 closed defect (fixed)

clang, llvm: don't use svn

Reported by: ryandesign (Ryan Schmidt) Owned by: jeremyhu (Jeremy Huddleston Sequoia)
Priority: Normal Milestone:
Component: ports Version: 2.1.2
Keywords: Cc:
Port: clang-2.9, clang-3.0, clang-3.1, clang-3.2, llvm-2.9, llvm-3.0, llvm-3.1, llvm-3.2


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} compiler-rt"

The post-extract block of clang-3.0 runs:

system "cd ${worksrcpath}/projects && svn co -r ${compiler_rt_rev} compiler-rt"

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

system "cd ${worksrcpath}/projects && svn co -r ${libcxx_rev} libcxx"

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

system "cd ${worksrcpath}/projects && svn co -r ${libcxx_rev} 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?

Change History (2)

comment:1 Changed 8 years ago by 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.

comment:2 Changed 8 years ago by jeremyhu (Jeremy Huddleston Sequoia)

Resolution: fixed
Status: newclosed

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

Note: See TracTickets for help on using tickets.