Re: [PATCH] * config.sub: Cordon off single-component aliases
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
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
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
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, Earniewrote: 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
"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, Earniewrote: 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
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
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 +