>>Nathanael Nerode wrote: It's in now, BTW. Nothing broke. :-) (As I notified when I submitted the patch as an FYI prior to stage 1 opening, this was checked with a native bootstrap *and* a cross build.)
>>The libada-gnattools-branch suffers severely from having to be maintained >>in parallel with mainline (since it's a rearrangment of existing code). >>Another two months of waiting will necessitate many hours of totally >>unneccessary work on my part. > >The same is true for everyone who has to wait to check in a patch. No, it isn't. This patch consisted of large code relocation and rearrangement with few semantic changes. This means that whenever logic changes are made on mainline, I have to manually port them over to the relocated code. It contains a new directory and relocated/split files, which would be easy enough to maintain on a branch under SVN, but under CVS, *SUCKS BIG TIME*. I have been maintaining this essentially ready since sometime early in stage 2 for 4.0. I was delayed by tree-ssa breakage in Ada bootstrap, making it impossible to test my changes fully until sometime in stage 3, by which time it was unsuitable. >If it breaks bootstrap, it will definitely interfere. It *can't* break non-Ada bootstrap (which is, BTW, still the default), unless the commit was screwed up or incomplete. It is fully tested for Ada bootstrap, plus I'm committed to fixing any breakage. >If it causes patch conflicts with other changes it will also interfere. It can only cause conflicts with Ada changes, none of which are scheduled for stage 1. And it's actually quite unlikely that it will cause those. If it does, I certainly intend to resolve the conflicts in any such Ada patches; the changes are mostly code relocation, so patch adaptation should be easy. >And if it doesn't cause any patch conflicts, then it probably won't be >very hard to maintain on a branch. Except that it *was*. I had to maintain five sets of ChangeLog entries and a new directory. Merges from trunk took ridiculous time, since I was pulling in vastly larger changes from mainline than the entire set of changes on the branch. But most importantly, I had to watch every change to libada and gcc/ada/Makefile.in to see if it happened to be in one of the sections of code which was being moved to a different file, so that I could copy the change over. :-P (Again, most of this would be relatively easy to handle, being mostly automatic, under SVN, but it's hours and hours under CVS.) In addition, all further progress in this direction was stalled. Problems which can be remedied relatively easily now were causing lots of discussion and progressively more kludgy patches were showing up. Getting this in now makes it substantially more likely that I'll be able to finish additional improvements to the build system (for Ada and for other projects) to commit in stage 2. Otherwise, I'd be spending all my time just keeping this patch applying cleanly and correctly, without doing any changes at all. -- Finally, let me quote the development plan: "Although maintaining a development branch, including merging new changes from the mainline, is somewhat burdensome, the absolute worst case is that such a branch will have to be maintained for four months." I have already maintained this patchset essentially unchanged for four months, without complaining at all. Two more months is not acceptable. -- This space intentionally left blank.
