Re: [PATCH] * config.sub: Cordon off single-component aliases

2018-05-18 Thread Ben Elliston
Thanks, applied.

Ben


signature.asc
Description: PGP signature
___
config-patches mailing list
config-patches@gnu.org
https://lists.gnu.org/mailman/listinfo/config-patches


Re: [PATCH] * config.sub: Cordon off single-component aliases

2018-05-18 Thread Paul Eggert

On 05/18/2018 05:42 PM, Ben Elliston wrote:

${parameter:-word} is in POSIX, but I don't know how portable it is to
old Bourne shells.  Paul?


Although it does not work on old Bourne shells, I suspect we don't need 
to worry about them any more.


The "Shellology" section of the Autoconf manual says ${VAR:-VALUE} 
causes old BSD shells to complain and die, and mentions Ultrix. However, 
as far as I know these old shells are now museum pieces. The last Ultrix 
release was in 1995. I haven't fielded an Ultrix bug report for many years.


For what it's worth, 'configure' scripts are still portable to Ultrix 
because they search for a POSIX-compatible shell by trying a list of 
programs that includes 'sh5', which was how Ultrix did it. I think this 
was due to the late Fred Canter, who specialized in getting the farkles 
out.  See:


Hall J. The last farkle. Linux J. 2007-12-02. 
https://www.linuxjournal.com/node/1005779



___
config-patches mailing list
config-patches@gnu.org
https://lists.gnu.org/mailman/listinfo/config-patches


Re: [PATCH] * config.sub: Cordon off single-component aliases

2018-05-18 Thread Ben Elliston
On Thu, May 17, 2018 at 05:57:20PM -0400, John Ericson wrote:

> The 4th and last rule is the trickiest, and most fuzzy human. If the
> basic_machine was left as as, or appended with a vendor, I
> considered the pattern less an alias, and more a defaulting of a
> canonical or near canonical name. This seemed like a "higher
> quality" short-hand and thus one that is valid as part of a larger
> config. Instead of just hard-assigning `os`, however, I changed it
> to default `os` with
> 
>   os=${os:-DEFAULT}

${parameter:-word} is in POSIX, but I don't know how portable it is to
old Bourne shells.  Paul?

Cheers,
Ben

___
config-patches mailing list
config-patches@gnu.org
https://lists.gnu.org/mailman/listinfo/config-patches


Re: [PATCH] * config.sub: Cordon off single-component aliases

2018-05-18 Thread John Ericson

To be really precise, with my change:

$ ./config.sub 386bsd-linux
Invalid configuration `386bsd-linux': machine `386bsd' not recognized

$ ./config.sub 386bsd
i386-pc-bsd

$ ./config.sub mingw32-bsd
Invalid configuration `mingw32-bsd': machine `mingw32' not recognized

$ ./config.sub mingw32
i686-pc-mingw32

John

On 05/18/18 13:11, John Ericson wrote:
"mingw32" would still work. Indeed I do not want to break 
compatability on intended short-hands like that. But "mingw32-vms" or 
something rediculous like that will no longer. (The "vms" is ignored 
currently.)


John

On May 18, 2018 10:00 AM, Earnie  wrote:



On 5/17/2018 5:57 PM, John Ericson wrote:
> Currently, there are number of aliases that expand both on their
own and as
> part of multi-component configurations. For example:
>
> $ ./config.sub 386bsd-linux
> i386-pc-bsd
>
> This change moves all of those to just trigger on a single field
branch,
> preventing their matching as part of larger components:
>
> $ ./config.sub 386bsd-linux
> Invalid configuration `386bsd-linux': machine `386bsd' not
recognized
>

This would not be kind.  I expect that config.sub gives the proper
triplet when doing ./config.sub mingw32.  Or am I not
understanding you?

The reason ./config.sub mingw32 returns the proper triplet is because
historically people, including many developers, have no idea what
i386-pc-mingw32 means when GCC and binutils creates a directory so
--host=mingw32 is given to create a mingw32 directory instead.

-- 
Earnie


___
config-patches mailing list
config-patches@gnu.org
https://lists.gnu.org/mailman/listinfo/config-patches




___
config-patches mailing list
config-patches@gnu.org
https://lists.gnu.org/mailman/listinfo/config-patches



___
config-patches mailing list
config-patches@gnu.org
https://lists.gnu.org/mailman/listinfo/config-patches


Re: [PATCH] * config.sub: Cordon off single-component aliases

2018-05-18 Thread John Ericson
"mingw32" would still work. Indeed I do not want to break compatability on intended short-hands like that. But "mingw32-vms" or something rediculous like that will no longer. (The "vms" is ignored currently.)JohnOn May 18, 2018 10:00 AM, Earnie  wrote:



On 5/17/2018 5:57 PM, John Ericson wrote:

> Currently, there are number of aliases that expand both on their own and as

> part of multi-component configurations. For example:

> 

> 	$ ./config.sub 386bsd-linux

> 	i386-pc-bsd

> 

> This change moves all of those to just trigger on a single field branch,

> preventing their matching as part of larger components:

> 

> 	$ ./config.sub 386bsd-linux

> 	Invalid configuration `386bsd-linux': machine `386bsd' not recognized

> 



This would not be kind.  I expect that config.sub gives the proper

triplet when doing ./config.sub mingw32.  Or am I not understanding you?



The reason ./config.sub mingw32 returns the proper triplet is because

historically people, including many developers, have no idea what

i386-pc-mingw32 means when GCC and binutils creates a directory so

--host=mingw32 is given to create a mingw32 directory instead.



-- 

Earnie



___

config-patches mailing list

config-patches@gnu.org

https://lists.gnu.org/mailman/listinfo/config-patches


___
config-patches mailing list
config-patches@gnu.org
https://lists.gnu.org/mailman/listinfo/config-patches


Re: [PATCH] * config.sub: Cordon off single-component aliases

2018-05-18 Thread Earnie


On 5/17/2018 5:57 PM, John Ericson wrote:
> Currently, there are number of aliases that expand both on their own and as
> part of multi-component configurations. For example:
> 
>   $ ./config.sub 386bsd-linux
>   i386-pc-bsd
> 
> This change moves all of those to just trigger on a single field branch,
> preventing their matching as part of larger components:
> 
>   $ ./config.sub 386bsd-linux
>   Invalid configuration `386bsd-linux': machine `386bsd' not recognized
> 

This would not be kind.  I expect that config.sub gives the proper
triplet when doing ./config.sub mingw32.  Or am I not understanding you?

The reason ./config.sub mingw32 returns the proper triplet is because
historically people, including many developers, have no idea what
i386-pc-mingw32 means when GCC and binutils creates a directory so
--host=mingw32 is given to create a mingw32 directory instead.

-- 
Earnie

___
config-patches mailing list
config-patches@gnu.org
https://lists.gnu.org/mailman/listinfo/config-patches


[PATCH] * config.sub: Cordon off single-component aliases

2018-05-17 Thread John Ericson
Currently, there are number of aliases that expand both on their own and as
part of multi-component configurations. For example:

$ ./config.sub 386bsd-linux
i386-pc-bsd

This change moves all of those to just trigger on a single field branch,
preventing their matching as part of larger components:

$ ./config.sub 386bsd-linux
Invalid configuration `386bsd-linux': machine `386bsd' not recognized

This should increase correctness, and avoid needless work in the common case
(as much of these are very very old).

I was very conservative in deciding which patterns which such single component
aliases, as this does make config.sub less forgiving than before. My criteria
for patterns in this `case $basic_machine in` were:

- The pattern doesn't contain any `-`
- The pattern doesn't contain any `*`
- `os` was assigned in the match body
- basic_machine wasn't essentially left as is.

The first rule is simple, if it contains a `-` it's not a single-component
pattern. The second rule is because any `$basic_machine` pattern with an
asterisk (`*`) could conceivable match a two component string, even if the
actual code strongly signaled that was not the intent. The third rule was to
indicate no `os` was expected, as it is valid to omit a vendor in the two
component case so `basic_machine` is just one component without being the
entire configuration.

The 4th and last rule is the trickiest, and most fuzzy human. If the
basic_machine was left as as, or appended with a vendor, I considered the
pattern less an alias, and more a defaulting of a canonical or near canonical
name. This seemed like a "higher quality" short-hand and thus one that is valid
as part of a larger config. Instead of just hard-assigning `os`, however, I
changed it to default `os` with

os=${os:-DEFAULT}

so as to respect any more information the user passed. This gives us
more pleasant absurdities like:

$ ./config.sub j90
j90-cray-unicos

$ ./config.sub j90-linux
j90-cray-linux-gnu

rather than deceitful:

$ ./config.sub j90-linux
j90-cray-unicos

Whether we want to even allow things like `j90-linux` I leave as less-
conservative follow-up work.

Cheers,

John
---
 ChangeLog  |   4 +
 config.sub | 791 +++--
 2 files changed, 404 insertions(+), 391 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 59f787a..d42bf56 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,7 @@
+2018-05-14  John Ericson  
+
+   * config.sub: Cordon off single-component aliases.
+
 2018-05-14  John Ericson  
 
* config.sub: Don't prepend $os with '-' everywhere. Include it in
diff --git a/config.sub b/config.sub
index 0b4a950..c491d7d 100755
--- a/config.sub
+++ b/config.sub
@@ -2,7 +2,7 @@
 # Configuration validation subroutine script.
 #   Copyright 1992-2018 Free Software Foundation, Inc.
 
-timestamp='2018-05-14'
+timestamp='2018-05-17'
 
 # This file is free software; you can redistribute it and/or modify it
 # under the terms of the GNU General Public License as published by
@@ -153,8 +153,390 @@ case $1 in
os=$field2
;;
*)
-   basic_machine=$1
-   os=
+   # Convert single-component short-hands not valid as part of
+   # multi-component configurations.
+   case $field1 in
+   386bsd)
+   basic_machine=i386-pc
+   os=bsd
+   ;;
+   a29khif)
+   basic_machine=a29k-amd
+   os=udi
+   ;;
+   adobe68k)
+   basic_machine=m68010-adobe
+   os=scout
+   ;;
+   am29k)
+   basic_machine=a29k-none
+   os=bsd
+   ;;
+   amdahl)
+   basic_machine=580-amdahl
+   os=sysv
+   ;;
+   amigaos | amigados)
+   basic_machine=m68k-unknown
+   os=amigaos
+   ;;
+   amigaunix | amix)
+   basic_machine=m68k-unknown
+   os=sysv4
+   ;;
+   apollo68)
+   basic_machine=m68k-apollo
+   os=sysv
+   ;;
+   apollo68bsd)
+   basic_machine=m68k-apollo
+   os=bsd
+