I mentioned this to brian, and he pointed out that test/Regression/CFrontend and
other tests that depend on the C front-end should be moved as well...

-Chris

Changing all of these bugs who do not have people looking at them to be assigned
to "unassignedbugs", indicating that if someone is feeling ambitious, they can
take ownership of the bug.

If I stole your bug, and you still want it, feel free to take ownership back.

-Chris

Here's something that I sent to John just today:

In theory, it sounds like we want
a directory layout like this:

llvm/
lib/...
include/...
test/
Feature/
Regression/...
...
projects/
c-frontend/
gcc/...
test/
C++Regression/...
CRegression/...
runtime/
crtend/
Stacker/...
Libraries/
libz/
libpng/
libc/
...
TestPrograms/
MultiSource/...
SingleSource/...
External/...

The idea being that everything under projects is optional. We could
rename "projects" to "modules", and be set. I think that this would
achieve what we want (make test/Programs optional, pull stuff out of the
main CVS tree, simplify dependencies, etc).

What do you think?

-Chris

The basic idea looks good, with one minor tweak that I would like to suggest.

One of the ideas behind CVS is the notion of "modules" which tyipcally
correspond to the top level directory names (although they don't have to). We
currently have one "llvm" module with everything under it. While stating that
"projects" is optional, it will still be checked out when someone does:

cvs -d :pserver:anon@llvm-cvs.cs.uiuc.edu:/var/cvs/llvm checkout .

I think the repository should be made a little flatter, structured this way:

/var/cvs/llvm/llvm - Everything you have under /llvm
/var/cvs/llvm/c-frontend - Everything you have under /llvm/Projects/c-frontend
/var/cvs/llvm/projects - Stacker, examples, etc.
/var/cvs/llvm/test - What you have under /llvm/Projects/TestPrograms

This way, one can set CVSROOT to .../var/cvs/llvm
and get everything with: cvs -d .../var/cvs/llvm co .
or get just the core with: cvs -d .../var/cvs/llvm co llvm
or get just the test suite wth: cvs -d ../var/cvs/llvm co test
or get just the projects with: cvs -d ../var/cvs/llvm co projects

I believe this arrangement works for everyone. Developers of LLVM can just use
"cvs ... co ." which garners them everything. Users of LLVM can select which
piece they want with the appropriate co shown above.

Also with this arrangement you can go to the top of your checkout directory and
just "cvs update" to update individual portions. With the structure you
suggested, if I went to /llvm and did "cvs update", I would end up updating all
the projects and TestPrograms as well as the core and the c-frontend. This isn't
what I want most of the time. Generally, I just want the core. Occassionally I
want stacker. I never want the test programs (other than the regressions in the
core), and I'm afraid of the c-frontend :) The alternative right now is to
visit all the top level directories under llvm
(lib,include,docs,autoconf,runtime,tools) and cvs update each of them. Yuck! :)

Reid.

Oh yeah, I forgot to mention, that this was similar to the plan. We already do
exactly this with the projects system, which is why I put all of the optional
stuff in the project subdir. For example, we have an 'internal cvs' repo that
has things like the pool allocator, reoptimizer, and other misc stuff in it. To
work on the pool allocator, I just check out that module under the projects
directory. Since CVS is recursive, it automatically goes into that directory
and doesn't even notice that it's in a different repo. :)

When packaging the release, the different CVS modules would go into different
tarballs/rpms/debs/whatever, and the default checkout would JUST give you LLVM.
To get the testsuite, you would have to check out its module as well.

-Chris

The --enable-jit and --enable-llc_diffs options should move from the main configure
script to the test/Programs configure script, as well.

The conversion has been completed. John C did the basic work of creating a new
cvs module (llvm-test) that contained the test scripts and basic autoconf
support. I polished that up and made it at least work for the nightly tester.
There may be a few other glitches that I haven't found yet, but the build of the
work is done and it works.

SOOOO .. here's what you need to know:

1. llvm/test/Programs is now "empty"

2. llvm/test/Regression and llvm/test/Feature remain, unchanged

3. to build the test suite you need to:
   cd $LLVM_SRC_ROOT/projects
   cvs co -PR llvm-test
   cd $LLVM_OBJ_ROOT/projects
   $LLVM_SRC_ROOT/configure --with-llvmsrc=$LLVM_SRC_ROOT
   --with-llvmobj=$LLVM_OBJ_ROOT
   gmake

4. The llvm configure script will invoke the projects/llvm-test configure
   script properly if you'd rather do that.

5. In 1.4 the source tarball for llvm won't contain the Programs test suite
   which should make it significantly smaller.

6. The NightlyTest.pl script has been modified to take the above into account.

Happy Testing.

Reopen to assign.

Re-resolve after assignment.