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 <ear...@users.sourceforge.net> 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