* Joseph S. Myers wrote on Fri, Mar 18, 2011 at 08:46:56PM CET:
> On Fri, 18 Mar 2011, Ralf Wildenhues wrote:
>
> > > @@ -744,7 +744,6 @@ case "${target}" in
> > > libgloss_dir=cris
> > > ;;
> > > crx-*-*)
> > > - noconfigdirs="$noconfigdirs target-libstdc++-v3 target-mudflap
> > > ${libgcj}"
> > > ;;
> >
> > Why not also remove the line before and after this one?
> > Is that because crx is still supported in binutils or other
> > src projects? If yes, the hunk is fine, but then I wonder
> > whether it is too early to drop the config-ml.in bits for src.
>
> Yes, it is still supported in binutils
Then config-ml.in should not be changed yet, IIUC.
> - and the general reason for not
> removing the empty cases is that there are plenty of such cases already
> there, some for truly ancient targets.
I can understand keeping them when there are later case matches that
might match the pattern in question. That doesn't apply to crx-*-*
however.
(FWIW, my knowledge about history of GCC and binutils targets is really
limited, so I rely on others here.)
> It seems quite likely that some of
> the targets mentioned at toplevel actually have no useful support anywhere
> in gcc or src and that all of those target cases should be reviewed for
> usefulness and correctness.
Right, but that sounds like an independent task.
> (There are also lots of cases for "canonical
> aliases" that have been deprecated and removed from GCC - that is, names
> that should be aliases but that config.sub treats as canonical and so
> cause problems because of needing duplication in case statements etc.
> everywhere. In those cases it probably makes sense to remove support for
> the duplicate names in src, along maybe with making config.sub convert
> them to canonical form. i?86-*-pe as an alias for Cygwin is an example in
> the present patch; various such aliases were obsoleted in 4.3 as well, but
> support for "thumb-*" targets was obsolete long before the other ARM
> aliases obsoleted in 4.3.)
That's yet another task that might be a good idea to do (by somebody who
knows this in and out), but config.sub changes have the potential to
break or at least require adjustment in lots of other software. Many
packages look at those aliases, be that in their configury, or through
Libtool or gnulib or other third-party macros. I can't judge this well
without seeing a list of affected aliases (and even then it might be
hard).
Thanks,
Ralf
