Hi List, There is an outstanding bug, #257, pertaining to separating out the detailed testing infrastructure from the main LLVM code. I would like to see fixed in the 1.3 release time frame. The bug can be found here: http://llvm.cs.uiuc.edu/bugs/show_bug.cgi?id=257 I would have taken this one and done the work necessary but unfortunately I don't have CVS rights and this is almost completely a CVS job. There are a number of ancillary tasks that need to be done in conjunction with this task. Things like: - change configure.ac to _not_ support options that affect testing only. For example: --enable-spec200, --enable-spec95, --enable-povray. - change Makefiles to not build "test" - decide which portion(s) of test/Regression remain or are moved. I would like to volunteer to help with these things but it doesn't make sense without someone else to do the necessary CVS changes that go with it. The end goal of this change is to minimize the size of a standard distribution of LLVM and make configuration and building easier. What's the likelihood that someone could do this for 1.3, or the likelihood that I could get CVS access and do it myself? Reid. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20040413/b2a9ba42/attachment.sig>
On Tue, 13 Apr 2004, Reid Spencer wrote:> There is an outstanding bug, #257, pertaining to separating out the > detailed testing infrastructure from the main LLVM code. I would like to > see fixed in the 1.3 release time frame. The bug can be found here: > http://llvm.cs.uiuc.edu/bugs/show_bug.cgi?id=257I think that we would all like to see this bug fixed for 1.3. :) That said, we've all been really busy with a variety of things, and I don't think there are any definite plans to do it.> I would have taken this one and done the work necessary but > unfortunately I don't have CVS rights and this is almost completely a > CVS job.Well there are two big parts to it: changing the configure scripts and makefiles to work differently, and actually moving the files. The biggest part is changing the configure/makefile machinery... by contrast, moving the directory is easy. :)> There are a number of ancillary tasks that need to be done in > conjunction with this task. Things like: > > - change configure.ac to _not_ support options that affect testing only. > For example: --enable-spec200, --enable-spec95, --enable-povray. > > - change Makefiles to not build "test" > > - decide which portion(s) of test/Regression remain or are moved. > > I would like to volunteer to help with these things but it doesn't make > sense without someone else to do the necessary CVS changes that go with > it.Yes, definitely. I think the right way to do this is to make it be as incremental as possible. In particular, the biggest benefit will be to get llvm/test/Programs into a seperate tarball from the main LLVM tree, as it is big and will (hopefully!) keep getting bigger. There are several tasks that can be done incrementally to help out with this: 1. Make test/Programs be self contained, including not depending on makefiles in directories above it. 2. It should have its own (small) configure script, just like the other projects do. 3. It should "act" as if it were in llvm/projects/TestPrograms or something. Before the files are actually moved, this can be simulated with a symlink. Once these three are done, it should just be a matter of moving the CVS ,v files from llvm/test/Programs into llvm/projects/TestPrograms, and then into a seperate CVS module when that works goes well. I attached a small draft of one vision of a future LLVM directory layout to the end of PR257. Please take a look and add a comment if you think that something else would make sense.> The end goal of this change is to minimize the size of a standard > distribution of LLVM and make configuration and building easier.This is *clearly* a useful change :)> What's the likelihood that someone could do this for 1.3,At this point, I would not say that it's particularly likely that someone will do it straight out for 1.3. If you'd like to send in some patches for the three items above, we would be happy to apply them, and when the time comes, do the big move. If you get it to the point where we just have to move the files, I can guarantee that it will be done by 1.3. :)> or the likelihood that I could get CVS access and do it myself?At this point, sending in patches is probably the easiest thing to do. Figuring out how to set up the permissions, deal with the politics of giving external access to university machines, and other annoying details is just not something that is very appealing to me, and the actual CVS work is pretty small. -Chris -- http://llvm.cs.uiuc.edu/ http://www.nondot.org/~sabre/Projects/
On Tue, 2004-04-13 at 19:10, Chris Lattner wrote:> Yes, definitely. I think the right way to do this is to make it be as > incremental as possible. In particular, the biggest benefit will be to > get llvm/test/Programs into a seperate tarball from the main LLVM tree, as > it is big and will (hopefully!) keep getting bigger. There are several > tasks that can be done incrementally to help out with this: > > 1. Make test/Programs be self contained, including not depending on > makefiles in directories above it. > 2. It should have its own (small) configure script, just like the other > projects do. > 3. It should "act" as if it were in llvm/projects/TestPrograms or > something. Before the files are actually moved, this can be simulated > with a symlink. >This is completely opposite the way I work. If I had CVS access, I would do the whole change in a branch. This would include fixing all makefiles, moving all files, creating/fixing configure scripts, and running all regressions to make sure it worked. I would then check in the branch, merge mainline into it again and re-test. Once I was synched with mainline and everything checked out, I'd commit again. The branch would be verified independently by someone else before being merged back to mainline. Trying to do a global change in a piecemeal fashion will just create pain for more people. For example, how would I supply a patch to autoconf/configure.ac that removes support for, say --enable-spec2000 and that still lets you configure for testing? Attempting to do this piecemeal (or "incrementally" as you put it :) will just lead to confusion for everyone. Trust me, I've been there and done that.> Once these three are done, it should just be a matter of moving the CVS ,v > files from llvm/test/Programs into llvm/projects/TestPrograms, and then > into a seperate CVS module when that works goes well.I agree that moving the cvs files is a last step, but its also something that needs to be done incrementally as the solution is built in a branch.> > I attached a small draft of one vision of a future LLVM directory layout > to the end of PR257. Please take a look and add a comment if you think > that something else would make sense.Saw it, commented on it.> > > The end goal of this change is to minimize the size of a standard > > distribution of LLVM and make configuration and building easier. > > This is *clearly* a useful change :)Especially if you are over dialup or DSL :)> > At this point, sending in patches is probably the easiest thing to do. > Figuring out how to set up the permissions, deal with the politics of > giving external access to university machines, and other annoying details > is just not something that is very appealing to me, and the actual CVS > work is pretty small.Unfortunately, I won't be able to do that for this kind of project. The logistics of trying to keep track of a multitude of patches while at the same time keeping the build tree clean for other purposes is beyond the kind of time I have available. The reality of my work schedule is that I get very few concentrated periods of time to work on things. The way I handle this is by creating a branch that is separate from other things where I can work on a related set of changes. Other sets of changes are in other branches. I'm willing to help, but it has to be efficient with my time too. Thanks, Reid. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20040413/22504883/attachment.sig>