[LLVMdev] Repository Layout
sabre at nondot.org
Mon Jul 2 02:38:20 CDT 2007
On Sat, 30 Jun 2007, Reid Spencer wrote:
> I'm finding the current layout a bit frustrating, not to mention that it
> breaks all the documentation. We currently have modules laid out like
> and similarly for all the other modules (test-suite, java, poolalloc,
> etc.). Unfortunately, this "standard" layout interjects a directory
> (trunk/branches/tags) below each module name. I would rather see it laid
> out like this:
> Fortunately, with SVN, making such a change isn't hard and its tracked
> in the commits. Anyone object or have other ideas in this realm?
I strongly dislike this approach. This is particularly bad because we
have many subprojects. Lots of these subprojects are only loosly coupled
to LLVM: things like llvm-tv, llvm-java, llvm-poolalloc, etc.
I think that it is natural for subprojects to go through various
development phases and to sink or swim based on their own merits and the
contributor base around them. Our goal should be to make it as easy as
possible to check out the desired subset of LLVM and get going quickly.
Instead of trying to make a mega project, I suggest something else. What
I'd really like to see is this:
1. I check out the "llvm-project" into a directory. This provides some
very very basic makefiles and configure script stuff. This does not
try to solve all the worlds problems, it is just some simple glue.
2. Based on my interests, I check out a subset of the subprojects into
directories under llvm-project.
3. Each subproject knows the projects it depends on - either as a hard
dependency (requirement) or a soft dependency (optional component).
4. Once the stuff is checked out, you type "configure". Based on the glue
in #1, this checks to ensure that the various dependencies required are
checked out. If not, it errors out, telling you what else to check out
(or offering to do it for you?)
5. make, make test, make install, etc are provided by the glue. These
simply recurse into the subdirectories in the appropriate order and
invoke the respective targets.
With this design, I'd suggest refactoring the LLVM project a little bit.
I'd like to see:
1. a subproject for libsupport and libsystem.
2. a subproject for the rest of the "llvm" project. sometime later we can
separate out vmcore perhaps.
3. a subproject for llvm-gcc, which depends on #1 and #2.
4. a subproject for the new c front-end, which has a hard requirement on
#1 and a optional requirement for #2.
5. HLVM, llvm-tv, etc (the ones other people care about :)
One of the big in-between things is llvm-config. I've grown to *love*
this tool, but it only works for the main llvm project. I'd like to see
it move up and works as part of the glue, so that it is easy to
link/include anything that is part of the "llvm-project".
The overall goal is to make the system more modular (NOT more monolithic)
and to make it easier to get stuff started: it should be enough to check
out the llvm-project glue (very very quick checkout) and run "make
As an aside, I've been working on a revamp of the website, to make *it*
more modular, which is also required for the docs. I think it's
amazing(ly bad) that we don't have a documentation subsection for llvm-gcc
More information about the LLVMdev