This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: m68k MacOS target support?


Joe Buck wrote:
> 
> >     lars> I certainly don't expect the maintainers to actively
> >     lars> maintain the PDP-10 back end, or even care much if it
> >     lars> breaks.
> 
> Mark writes:
> > What's funny about these kinds of things is how hard it is to undo
> > anything.  Whenever I propose getting rid of a "feature" in GCC, I
> > find that people now rely on that feature, or that at least many
> > people are afraid people rely on that feature.  Support for a platform
> > is a feature.  Once support is in GCC, it will probably be somewhat
> > difficult to remove that support.
> 
> The approach gcc has taken to this problem in the past (whether we want
> to admit it or not) is to just let the uninteresting ports slowly degrade
> due to bit rot.  This has the disadvantage that it can make gcc look bad,
> but if a committed user comes along at some point there is hope that the
> broken port can be fixed.  Given this it is probably better to leave the
> ports in, with warnings about which ones have been tested and which ones
> are likely to have problems.

For GDB we had the problem that many of GDB's porting constructs had
been deprecated or retired, the only references left were in obsolete
ports, and new developers were being misled by their existence - in a
couple cases spending extra work trying to update ports that had no
chance of working.  Worse, with GDB it's possible to have native
ports whose code literally cannot be compiled anywhere else.  So I
discussed this with RMS and came up with a obsoletion scheme, where
old code is prominently marked as obsolete (by commenting out every
line), announced as such in a release, and if nobody has come forward
to revive it by the time of the next release, it gets completely removed.

So far only a handful of targets have been proved obsolete and gotten
this treatment - Gould and Pyramid (pre-Mips) are the most notable.

Stan

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]