I'm working up some changes in the way LLVM is released. Attached is the latest HTML file for HowToReleaseLLVM.html. The major change is in how we do branching and tagging. I want to use a hierarchical version of tags for the various release candidates and final release. The structure of the tags would be something like this.
Once created, the tags will never change. The branch may change. Though after the final release the branch shouldn't really change.
Duncan brought up the question of how to release clang. It would be nice to package clang by itself without all of the LLVM tools. Basically, making it a standalone package. I have no problem with this (in fact, I think it's a great idea), but it does mean changing Makefiles and stuff. Any help with this would be greatly appreciated.
We were discussing exactly that this week. With Clang inside LLVM's
tree, it's hard for us to create separate (internal) products for
them, so we can build and test them separately (EDG+LLVM against
Clang+LLVM). But I'm not sure we're the most common types of users...
I believe the Debian package for Clang is separate from LLVM, which
makes sense, but that might be hard to produce, given that they're too
tightly coupled... Debian maintainers would know more...
I'm working up some changes in the way LLVM is released. Attached is the latest HTML file for HowToReleaseLLVM.html. The major change is in how we do branching and tagging. I want to use a hierarchical version of tags for the various release candidates and final release. The structure of the tags would be something like this.
Once created, the tags will never change. The branch may change. Though after the final release the branch shouldn't really change.
This seems like a good improvement to me.
Duncan brought up the question of how to release clang. It would be nice to package clang by itself without all of the LLVM tools. Basically, making it a standalone package. I have no problem with this (in fact, I think it's a great idea), but it does mean changing Makefiles and stuff. Any help with this would be greatly appreciated.
While that would be nice, I doubt it makes sense for 2.9. We probably
need the feature work on the Makefiles etc. to happen on TOT first,
before we consider leveraging that in the release process.
We're doing separate builds in the FreeBSD ports collection. You have
to have the LLVM source try around and we configure against the whole
tree, but we can build against and installed version of llvm with only a
few hacks. The basic process is:
- extract llvm and clang sources.
cd <llvm-src-root>
./configuire <args>
ln -s ${PREFIX}/include/llvm/Intrinsics.gen <llvm-src-root>/include/llvm
cd utils/unittest/googletest
gmake
cd <llvm-src-root>/tools/clang
gmake
gmake install
The need to build googletest is relatively recent. Oddly, if you just
install libGoogleTest.a as part of the LLVM package build you get build
errors.
