Re: foo.s

[Roland McGrath <roland@hack.frob.com>]

> It looks like only Alpha and HPPA have foo.s files any longer.

Then libc-ports is the place that needs to hear the request (CC'd).

> I did a quick scan over them in the glibc-ports tree and I see no
> reason why changing them all over to foo.S would break things.

I can't imagine how it would.  (Actually I can, if there are foo.s files
using identifiers that $(compile-command.S) predefines.  But it doesn't
seem inordinately likely--who would be as foolish as i686?)

> Could someone do that?

If the respective port maintainers don't respond very quickly, then it's
very reasonable to do and post your own renaming changes (just one big one
for each machine).  If they don't all respond to that posting within a few
days, then it's reasonable in a case like this to commit it yourself even
without basic build-testing just on the approval of a general maintainer
like me and just leave it to the (thoroughly forewarned) port maintainer to
fix up any fallout.

> Then I could commit the change to remove support for *.s files and
> thus the overhead of the resulting sysdep prefix rules.

As a matter of policy when only two less-often-maintained machines are
affected, it's acceptable to make the request, wait a tiny grace period,
and then just break them so they have to do the updates themselves.  But in
a case like this where you surely can do a blind renaming fine without
knowing anything about the particular machine, it's friendly to offer the
legwork yourself as outlined above.

When you do this, be sure to scour all the corners of all the makefile
fragments and ancillary scripts to excise every .s mention.  I somehow feel
obliged to think that there will be more of them than one might think.


Thanks,
Roland