Target deprecation, round four

Target deprecation, round four

[Zack Weinberg]

Fairly small adjustments from the last set.  If there are no further
objections I'd like to patch this list into the 3.3 branch and begin
deleting code from the mainline.

zw

	arc-*-*
        i960-*-*
        m88k-*-*
        romp-*-*

	alpha*-*-interix*
	alpha*-*-linux*libc1*
	alpha*-*-linux*ecoff*

	arm*-*-aout*
	arm*-*-conix*
	arm*-*-oabi
	strongarm-*-coff*

	hppa1.0-*-osf*
	hppa1.0-*-bsd*
	hppa1.[01]-*-hpux[789]*
	hppa*-*-hiux*
	hppa*-*-lites*
	hppa*-*-mpeix*

	i?86-ncr-*
	i?86-sequent-*
	i?86-moss-*
	i?86-*-netware
	i?86-*-freebsd2*
	i?86-*-netbsd*aout*
	i?86-*-linux*aout*
	i?86-*-moss*
	i?86-*-sysv3*
	i?86-*-vsta
	i?86-*-interix # not interix3

	m68000-hp-bsd*
	m68000-hp-hpux*
	m68000-sun-sunos*
	m68000-att-sysv*
	m68k-atari-sysv*
	m68k-motorola-sysv*
	m68k-ncr-sysv*
	m68k-plexus-sysv*
	m68k-tti-*
	m68k-crds-unos*
	m68k-cbm-sysv*
	m68k-ccur-rtu*
	m68k-hp-bsd*
	m68k-hp-hpux*
	m68k-sun-mach*
	m68k-sun-sunos*
	m68k-*-linux*aout*
	m68k-*-linux*libc1
	m68k-*-psos*

	mips*-*-ecoff*
        mips-sni-sysv4
	mips64orion-*-rtems*

	powerpc*-*-sysv*  # generic only; consider -elf instead
	powerpc*-*-linux*libc1
	rs6000-ibm-aix[123]*
	rs6000-bull-bosx
	rs6000-*-mach*

	sparc-*-aout*
	sparc-*-netbsd*aout*
	sparc-*-bsd*
	sparc-*-chorusos*
	sparc-*-linux*aout*
	sparc-*-linux*libc1*
	sparc-*-lynxos*
	sparc-hal-solaris2*
	sparc-*-sunos[34]*
	sparclet-*-aout*
	sparclite-*-coff*
	sparclite-*-aout*
	sparc86x-*-aout*

	v850-*-rtems*

	vax-*-bsd*
	vax-*-sysv*
	vax-*-netbsd*aout*
        vax-*-vms*

Re: Target deprecation, round four

[Christopher Faylor]

On Mon, Mar 03, 2003 at 09:29:16PM -0800, Zack Weinberg wrote:
>Fairly small adjustments from the last set.  If there are no further
>objections I'd like to patch this list into the 3.3 branch and begin
>deleting code from the mainline.

Zack,
Danny Smith has recently determined that you can eliminate the
i[34567]86-*-win32 target, too.  Could you add that to your list?
This means that you can also remove config/i386/win32.h entirely.

I was going to do this but it might make sense to eliminate all of
the obsolete targets in one go.

cgf

>	arc-*-*
>        i960-*-*
>        m88k-*-*
>        romp-*-*
>
>	alpha*-*-interix*
>	alpha*-*-linux*libc1*
>	alpha*-*-linux*ecoff*
>
>	arm*-*-aout*
>	arm*-*-conix*
>	arm*-*-oabi
>	strongarm-*-coff*
>
>	hppa1.0-*-osf*
>	hppa1.0-*-bsd*
>	hppa1.[01]-*-hpux[789]*
>	hppa*-*-hiux*
>	hppa*-*-lites*
>	hppa*-*-mpeix*
>
>	i?86-ncr-*
>	i?86-sequent-*
>	i?86-moss-*
>	i?86-*-netware
>	i?86-*-freebsd2*
>	i?86-*-netbsd*aout*
>	i?86-*-linux*aout*
>	i?86-*-moss*
>	i?86-*-sysv3*
>	i?86-*-vsta
>	i?86-*-interix # not interix3
>
>	m68000-hp-bsd*
>	m68000-hp-hpux*
>	m68000-sun-sunos*
>	m68000-att-sysv*
>	m68k-atari-sysv*
>	m68k-motorola-sysv*
>	m68k-ncr-sysv*
>	m68k-plexus-sysv*
>	m68k-tti-*
>	m68k-crds-unos*
>	m68k-cbm-sysv*
>	m68k-ccur-rtu*
>	m68k-hp-bsd*
>	m68k-hp-hpux*
>	m68k-sun-mach*
>	m68k-sun-sunos*
>	m68k-*-linux*aout*
>	m68k-*-linux*libc1
>	m68k-*-psos*
>
>	mips*-*-ecoff*
>        mips-sni-sysv4
>	mips64orion-*-rtems*
>
>	powerpc*-*-sysv*  # generic only; consider -elf instead
>	powerpc*-*-linux*libc1
>	rs6000-ibm-aix[123]*
>	rs6000-bull-bosx
>	rs6000-*-mach*
>
>	sparc-*-aout*
>	sparc-*-netbsd*aout*
>	sparc-*-bsd*
>	sparc-*-chorusos*
>	sparc-*-linux*aout*
>	sparc-*-linux*libc1*
>	sparc-*-lynxos*
>	sparc-hal-solaris2*
>	sparc-*-sunos[34]*
>	sparclet-*-aout*
>	sparclite-*-coff*
>	sparclite-*-aout*
>	sparc86x-*-aout*
>
>	v850-*-rtems*
>
>	vax-*-bsd*
>	vax-*-sysv*
>	vax-*-netbsd*aout*
>        vax-*-vms*

Re: Target deprecation, round four

[Zack Weinberg]

Christopher Faylor <cgf@redhat.com> writes:

> On Mon, Mar 03, 2003 at 09:29:16PM -0800, Zack Weinberg wrote:
>>Fairly small adjustments from the last set.  If there are no further
>>objections I'd like to patch this list into the 3.3 branch and begin
>>deleting code from the mainline.
>
> Zack,
> Danny Smith has recently determined that you can eliminate the
> i[34567]86-*-win32 target, too.  Could you add that to your list?

Sure.

zw

Re: Target deprecation, round four

[Richard Earnshaw]

zack@codesourcery.com said:
> Fairly small adjustments from the last set.  If there are no further
> objections I'd like to patch this list into the 3.3 branch and begin
> deleting code from the mainline. 

Surely a release containing the deprecation announcement should be made 
*before* we start removing the code...  As it stands you are proposing to 
delete the code from the mainline before most of the world is even aware 
of this.

I haven't seen anything posted to gcc-announce about these proposed 
deprecations, so most of the world is going to be blissfully unaware of 
your proposal.

R.

Re: Target deprecation, round four

[Nathan Sidwell]

Zack Weinberg wrote:
> But a wider announcement should happen.  How about I send the list to
> gcc-announce now, and wait another week before making any actual
> changes?
you could also email somewhere like lwn@lwn.net for their development page.

nathan
-- 
Nathan Sidwell    ::   http://www.codesourcery.com   ::     CodeSourcery LLC
          The voices in my head said this was stupid too
nathan@codesourcery.com : http://www.cs.bris.ac.uk/~nathan/ : nathan@acm.org

Re: Target deprecation, round four

[Richard Earnshaw]

> Nathanael Nerode <neroden@twcny.rr.com> writes:
> 
> >Richard Earnshaw said:
> >>Surely a release containing the deprecation announcement should be
> >>made *before* we start removing the code...  As it stands you are
> >>proposing to delete the code from the mainline before most of the
> >>world is even aware of this.
> >
> > I deprecated vax-vms for 3.3 and promptly deleted it from mainline.
> > But this is because vax-vms (a) wasn't working, (b) hadn't been for
> > a long time, and (c) had over 10,000 lines of code devoted to it.  I
> > would agree that deletions of *working* targets be delayed until the
> > version with the deprecation has been released.  But deletions of
> > *non-working* targets, I think, can take place as soon as possible.
> 
> The trouble with this otherwise reasonable suggestion is, (a) I have
> no way to tell whether the majority of the targets on the list are
> still working; (b) we have no schedule for the 3.3 release.  Also, I
> am holding off on several performance patches that will involve
> touching lots of back-end code, because I don't want to waste time on
> targets that will be deleted in short order.  And it's not hard to
> pull a deleted target back from CVS if someone does turn up expressing
> interest.

Recovering the files is the easy part.  Knowing what has been changed in 
the interim is *significantly* harder.

> 
> But a wider announcement should happen.  How about I send the list to
> gcc-announce now, and wait another week before making any actual
> changes?

That at least would be an improvement.

In general I think I'd like to see a two release approach to this issue.  
In stage one a target is denoted "at risk", then at stage two it is 
deprecated on the branch and removed from the mainline.

That gives some time for a user to object and maybe find a maintainer.  Of 
course an objection with no maintainer is no objection (if they really 
care they'll sponsor a maintainer).

R.

Re: Target deprecation, round four

[Mark Ferrell]

I would like to volunteer taking over maintanance of the x?86-vsta platform
and getting it out of deprication before the delete occures.

--- Zack Weinberg <zack@codesourcery.com> wrote:
> Nathanael Nerode <neroden@twcny.rr.com> writes:
> 
> >Richard Earnshaw said:
> >>Surely a release containing the deprecation announcement should be
> >>made *before* we start removing the code...  As it stands you are
> >>proposing to delete the code from the mainline before most of the
> >>world is even aware of this.
> >
> > I deprecated vax-vms for 3.3 and promptly deleted it from mainline.
> > But this is because vax-vms (a) wasn't working, (b) hadn't been for
> > a long time, and (c) had over 10,000 lines of code devoted to it.  I
> > would agree that deletions of *working* targets be delayed until the
> > version with the deprecation has been released.  But deletions of
> > *non-working* targets, I think, can take place as soon as possible.
> 
> The trouble with this otherwise reasonable suggestion is, (a) I have
> no way to tell whether the majority of the targets on the list are
> still working; (b) we have no schedule for the 3.3 release.  Also, I
> am holding off on several performance patches that will involve
> touching lots of back-end code, because I don't want to waste time on
> targets that will be deleted in short order.  And it's not hard to
> pull a deleted target back from CVS if someone does turn up expressing
> interest.
> 
> But a wider announcement should happen.  How about I send the list to
> gcc-announce now, and wait another week before making any actual
> changes?
> 
> zw


=====
Mark Ferrell

__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/

Re: Target deprecation, round four

[Zack Weinberg]

Nathanael Nerode <neroden@twcny.rr.com> writes:

>Richard Earnshaw said:
>>Surely a release containing the deprecation announcement should be
>>made *before* we start removing the code...  As it stands you are
>>proposing to delete the code from the mainline before most of the
>>world is even aware of this.
>
> I deprecated vax-vms for 3.3 and promptly deleted it from mainline.
> But this is because vax-vms (a) wasn't working, (b) hadn't been for
> a long time, and (c) had over 10,000 lines of code devoted to it.  I
> would agree that deletions of *working* targets be delayed until the
> version with the deprecation has been released.  But deletions of
> *non-working* targets, I think, can take place as soon as possible.

The trouble with this otherwise reasonable suggestion is, (a) I have
no way to tell whether the majority of the targets on the list are
still working; (b) we have no schedule for the 3.3 release.  Also, I
am holding off on several performance patches that will involve
touching lots of back-end code, because I don't want to waste time on
targets that will be deleted in short order.  And it's not hard to
pull a deleted target back from CVS if someone does turn up expressing
interest.

But a wider announcement should happen.  How about I send the list to
gcc-announce now, and wait another week before making any actual
changes?

zw

Re: Target deprecation, round four

[Nathanael Nerode]

zack at codesourcery dot com said:
> Fairly small adjustments from the last set.  If there are no further
> objections I'd like to patch this list into the 3.3 branch and begin
> deleting code from the mainline. 

Richard Earnshaw said:
>Surely a release containing the deprecation announcement should be made 
>*before* we start removing the code...  As it stands you are proposing 
>to 
>delete the code from the mainline before most of the world is even 
>aware 
>of this.

I deprecated vax-vms for 3.3 and promptly deleted it from mainline.  But 
this is because vax-vms (a) wasn't working, (b) hadn't been for a 
long time, and (c) had over 10,000 lines of code devoted to it.  I would 
agree that deletions of *working* targets be delayed until the 
version with the deprecation has been released.  But deletions of 
*non-working* targets, I think, can take place as soon as possible.

--Nathanael