Re: PROPOSAL: Policy for obsoleting targets

[Zack Weinberg <zack at codesourcery dot com>]

The discussion in response to this proposal has been interesting.  It
seems that it was too radical, at least for the present time.  I would
like to make a few observations in defense of it, or at least a
similar plan, however.

One class of objections to the original proposal centers around its
being difficult or impossible to run the test suite against some
otherwise supported targets.  This is a serious problem in its own
right.  It can be partially addressed through documentation, and it
sounds like people are making plans to improve the documentation.  I
know a fair bit about building cross-toolchains, and will gladly lend
a hand there.  However, at least right now it sounds like a
requirement to run the testsuite is too strong.  I have no problem
with weakening the requirement there; perhaps a simple report of some
kind of successful build could suffice.

Another class of objections centers around there being targets which
are maintained, but not in the FSF's repository, and with little or no
communication between us and the people doing the maintenance.  First,
I'd argue that if GCC isn't usable out of the box on a major free
operating system, there's another serious problem right there (and,
again, I'm willing to help resolve it).  Second, yes, my proposal
would make these targets go away if something didn't change, but
please realize that the necessary effort to keep a target around is as
minimal as I think it is feasible to make it.  No more often than once
every six months, someone would have to try to build our source tree,
report that it works, and send us any necessary patches.  Note that I
did *not* say the patches have to get applied.  My suspicion is that
the alternate proposals which were kicking around would actually be
*more* burdensome on these people.

Someone asked why we want to get rid of targets which still work,
whether or not anyone is using them.  The answer is that, in the
present state of the GCC source tree, each unused target presents
an additional burden to maintainers of the common portions of GCC.
We are trying to clean up the back-end interface so that it has not
got tentacles into every last source file of the allegedly machine-
independent compiler.  This requires modifying all the targets.  It
is *not* simply a matter of "keeping them up to date with sed."
I've done a lot of this work, and the changes required have never
been that automated.

Furthermore, the changes that someone doing a global sweep makes are
never as thorough as they should be.  As an example, the VxWorks ports
languished for several years until Nathan and I took them over.  My
first act was to throw away every line of existing support code and
start from scratch.  It was easier to do that than to update them
piecemeal.  Then we left the new port alone for six months; when we
came back to it it had *already* decayed to the point where I had to
rewrite the whole of config/rs6000/vxworks.h, albeit not the entire
port.  (This work hasn't made it into the FSF's tree yet, but will
soon.)  The people who updated it in the interim were conscientious,
but they naturally did the minimum, and that still left the port well
behind the curve.  Because of this experience, I feel that keeping old
unused ports around is a disservice even to hypothetical future people
who want that old port.  They're going to wind up throwing it all away
anyway, and all the effort put into keeping that port nominally up to
date will have been wasted.

zw