criswell at illinois.edu
Thu Jul 28 15:16:06 PDT 2011
On 7/28/11 4:40 PM, David A. Greene wrote:
> Chris Lattner<clattner at apple.com> writes:
>> On Jul 25, 2011, at 3:22 PM, Jason Kim wrote:
>> Great point. A potential conversion to git should be motivated by its
>> benefits - assuming no development policy change - and that benefit
>> needs to be greater than the various costs of conversion.
> Here are the most important benefits I see for the LLVM projects:
> - git greatly simplifies the work for groups that want to keep a private
> repository for internal development but eventually want to move that
> code to the public repository. Right now, there is NO tool support
> for doing this. It is a royal pain.
> - git allows different groups to share a codebase outside of
> master/upstream. Think of two academic research groups who want to
> explore a new transformation but don't want that work pushed to the
> public until it's done and published. This kind of development has no
> support whatsoever in svn.
Just to offer an alternative perspective on the above point, I suspect
that one of the reasons why maintaining out-of-tree code is such a pain
is because people are adding their passes into LLVM instead of using the
LLVM projects system.
For those unfamiliar with it, the LLVM projects system allows external
software source trees to link into LLVM's build system. Source code in
the project uses LLVM header files and libraries just like in-tree code,
and project Makefiles look nearly identical to LLVM's Makefiles. The
whole purpose of the project system is to allow people to write their
own LLVM passes in their own source trees (which, of course, can live in
its own revision control system) as if they were writing in-tree code.
Moving code from a project into LLVM shouldn't be terribly difficult,
especially if you write it so that the code is within the llvm namespace
and you create a local include/llvm tree for header files (aside: we
didn't do this for SAFECode, which made the SAFECode patch to LLVM more
difficult than necessary to create. Live and learn).
The projects system is used extensively here at Illinois (the publicly
available SAFECode and Poolalloc projects use it, and we have another
three internal projects using it) and is documented at
I think the main drawback of the projects system is that it doesn't work
for modifications of LLVM (including core LLVM changes, changes to
existing transforms, and code-generator changes). However, for writing
transform/analysis passes and LLVM-based tools, it works fine.
-- John T.
> - git provides a set of tools built-in to interact with the submit patch
> -> review -> update patch -> submit patch iterative process. I'm
> thinking mainly things like git send-email, git rebase -i and git add -i.
> - git allows easy backtracking of decision points, allowing one to
> explore a line of development and then reformulate the set of commits
> made before actually sending them upstream to master. For me, it is
> more helpful to be able to just code up a feature and once it's
> working, go back and break out the individual patch sets into logical
> groups. I tend to poorly anticipate how a feature/fix should be
> presented to upstream before I've actually implemented it. git
> decouples those two activities.
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
More information about the llvm-dev