Re: GCC 4.1 Projects

[neroden at twcny dot rr dot com (Nathanael Nerode)]

>>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.