On Tue, 2004-04-13 at 20:17, Chris Lattner wrote:> I guess I don't understand why making these changes is not > straight-forward and incremental. It seems as though #1 is just strictly > local changes to llvm/test/Programs/Makefile.programs, with no other > changes. This can be tested and worked on exactly as you mentioned, and > there should be zero breakage in the process. >Not quite. The configure script contains hard coded partial paths from the root of the tree to all Makefiles, including those in llvm/test/Programs directory. I can't go changing the locations of files and the contents of the makefiles without also changing configure.ac. If I change configure.ac then it affects everyone. If it affects everyone, I need to do it on a branch. I can't do that without cvs access.> Once that is done, the configure script can be split into two pieces, > again, without breaking anything. Once the makefiles and configure script > are changed, it shouldn't matter where the directory lives.So, what you're saying is that I provide you with a patch that excises all of test/Programs/... from the llvm configure.ac and removes all the related --enable-xyz options. You check this in. Then what? You've now disabled your testing environment waiting for a subsequent patch from me that restores it in "some other directory". Or, were you going to check the configure.ac change into a branch. If so, then I have to work out of a branch that you're administering and we have synchronization problems. This is the part that gets time consuming. I can't retain things in both worlds because autoconf won't configure anything that isn't in a directory that is a descendant of ${top_srcdir}. Gack. Can't we just be subversive and use subversion? :) You invited that comment :) 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/f573f4b2/attachment.sig>
On Tue, 13 Apr 2004, Reid Spencer wrote:> > > I guess I don't understand why making these changes is not > > straight-forward and incremental. It seems as though #1 is just strictly > > local changes to llvm/test/Programs/Makefile.programs, with no other > > changes. This can be tested and worked on exactly as you mentioned, and > > there should be zero breakage in the process. > > > Not quite. The configure script contains hard coded partial paths from > the root of the tree to all Makefiles, including those in > llvm/test/Programs directory. I can't go changing the locations of files > and the contents of the makefiles without also changing configure.ac. If > I change configure.ac then it affects everyone. If it affects everyone, > I need to do it on a branch. I can't do that without cvs access.By far the *biggest* change that needs to be made is to get the test/Programs makefile independent of the rest of the makefile stuff. At least this *certainly* can be done by just changing Makefile.programs.> > Once that is done, the configure script can be split into two pieces, > > again, without breaking anything. Once the makefiles and configure script > > are changed, it shouldn't matter where the directory lives. > > So, what you're saying is that I provide you with a patch that excises > all of test/Programs/... from the llvm configure.ac and removes all the > related --enable-xyz options. You check this in.No, I would check in two patches, the one to remove it, and the one to add it in the new location.> Then what? You've now disabled your testing environment waiting for a > subsequent patch from me that restores it in "some other directory". Or,Why not check in both patches at the same time?> were you going to check the configure.ac change into a branch. If so, > then I have to work out of a branch that you're administering and we > have synchronization problems. This is the part that gets time > consuming. > > I can't retain things in both worlds because autoconf won't configure > anything that isn't in a directory that is a descendant of > ${top_srcdir}.I have no idea about the configure issues, as I (intentionally :) know very little about it. Just the makefile changes alone, which I do understand, are clearly a starting point.> Can't we just be subversive and use subversion? :) > You invited that comment :)I know. Perhaps someday we can make the change. In fact, there are CVS->subversion gateways. If there was a CVS->subversion gateway, couldn't you do your development on a subversion branch from the gateway? -Chris -- http://llvm.cs.uiuc.edu/ http://www.nondot.org/~sabre/Projects/
> I know. Perhaps someday we can make the change. In fact, there are > CVS->subversion gateways. If there was a CVS->subversion gateway, > couldn't you do your development on a subversion branch from the gateway?That's an interesting idea that I'll look into. However, I'm pretty certain any such gateway would still require me to log n to CVS or it would be a "read only" gateway which wouldn't be much use. One thing I *could* do is set up a gateway with subversion so that it keeps itself synchronized with CVS, do all my changes, etc. and then when you guys are ready to move to subversion just donate the whole (new) repository back to the LLVM project. Would you be interested in that? 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/20040414/6654ad5c/attachment.sig>