This will allow us to simplify the machinery for running the tests under test/Programs and also make build changes to the rest of the tree much more easily. The Programs subdirectory should be a different module in cvs which once dropped in under $srcdir/test, be picked up by configure, configured and integrated in the build process as it is today (in other words once it is checked out in the right place, running it should not be different than what it is today).
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.