Re: [PATCH] config.sub: Accept LLVM-style `$cpu-$vendor-windows-{gnu, mingw}`
Thank you very much Dmitry, and apologies for the duplicate emails. I seem to always forget I am subscribed with list@... not git@... :). Cheers, John On 7/3/23 15:50, Dmitry V. Levin wrote: On Mon, Jun 26, 2023 at 07:56:57PM -0400, John Ericson wrote: In older times, MinGW (GCC toolchain with modified windows headers) was the only free software toolchain for Windows. But now, LLVM has excellent support both for MinGW ABI and Microsoft's own. (The distinction matters for C++ more than C.) LLVM[1], Rust[2], and other projects have taken to differentiating these two as `...windows-gnu` vs `...windows-msvc`. I think that makes a lot of sense, as it correctly identifiers both their commonalities and their differences. I agree that makes sense. I've corrected the commit message a bit and applied. Thanks,
Re: [PATCH] config.sub: Accept LLVM-style `$cpu-$vendor-windows-{gnu, mingw}`
On Mon, Jun 26, 2023 at 07:56:57PM -0400, John Ericson wrote: > In older times, MinGW (GCC toolchain with modified windows headers) was > the only free software toolchain for Windows. But now, LLVM has > excellent support both for MinGW ABI and Microsoft's own. (The > distinction matters for C++ more than C.) > > LLVM[1], Rust[2], and other projects have taken to differentiating these > two as `...windows-gnu` vs `...windows-msvc`. I think that makes a lot > of sense, as it correctly identifiers both their commonalities and their > differences. I agree that makes sense. I've corrected the commit message a bit and applied. Thanks, -- ldv
[PATCH] config.sub: Accept LLVM-style `$cpu-$vendor-windows-{gnu, mingw}`
In older times, MinGW (GCC toolchain with modified windows headers) was the only free software toolchain for Windows. But now, LLVM has excellent support both for MinGW ABI and Microsoft's own. (The distinction matters for C++ more than C.) LLVM[1], Rust[2], and other projects have taken to differentiating these two as `...windows-gnu` vs `...windows-msvc`. I think that makes a lot of sense, as it correctly identifiers both their commonalities and their differences. A lot of MinGW-supporting software, most notably GCC itself, will presumably continue to use configs like `x86_64-pc-mingw32` and `i686-pc-mingw32`. That's fine; this patch doesn't normalize them away (like LLVM does) or remove them! If and when that software wants to support the MSVC ABI without requiring MSVC itself, they can switch to these newer configurations. [1]: https://github.com/llvm/llvm-project/blob/a18266473be1439d324059afa0e8b124f0466428/llvm/unittests/TargetParser/TripleTest.cpp#L1907-L1951 [2]: https://github.com/rust-lang/rust/blob/36fb58e433c782e27dd41034284e157cf86d587f/compiler/rustc_target/src/spec/mod.rs#L1255-L1271 --- config.sub| 11 +-- testsuite/config-sub.data | 2 ++ 2 files changed, 11 insertions(+), 2 deletions(-) diff --git a/config.sub b/config.sub index f6ede1d..f7e93ce 100755 --- a/config.sub +++ b/config.sub @@ -145,7 +145,8 @@ case $1 in nto-qnx* | linux-* | uclinux-uclibc* \ | uclinux-gnu* | kfreebsd*-gnu* | knetbsd*-gnu* | netbsd*-gnu* \ | netbsd*-eabi* | kopensolaris*-gnu* | cloudabi*-eabi* \ - | storm-chaos* | os2-emx* | rtmk-nova* | managarm-*) + | storm-chaos* | os2-emx* | rtmk-nova* | managarm-* \ + | windows-* ) basic_machine=$field1 basic_os=$maybe_os ;; @@ -1766,7 +1767,7 @@ case $os in ;; none) ;; - kernel* ) + kernel* | msvc* ) # Restricted further below ;; *) @@ -1785,6 +1786,8 @@ case $kernel-$os in ;; managarm-mlibc* | managarm-kernel* ) ;; + windows*-gnu* | windows*-msvc*) + ;; -dietlibc* | -newlib* | -musl* | -relibc* | -uclibc* | -mlibc* ) # These are just libc implementations, not actual OSes, and thus # require a kernel. @@ -1799,6 +1802,10 @@ case $kernel-$os in echo "Invalid configuration '$1': '$kernel' does not support '$os'." 1>&2 exit 1 ;; + *-msvc* ) + echo "Invalid configuration '$1': '$os' needs 'windows'." 1>&2 + exit 1 + ;; kfreebsd*-gnu* | kopensolaris*-gnu*) ;; vxworks-simlinux | vxworks-simwindows | vxworks-spe) diff --git a/testsuite/config-sub.data b/testsuite/config-sub.data index 3b622ab..bb19dc2 100644 --- a/testsuite/config-sub.data +++ b/testsuite/config-sub.data @@ -865,6 +865,8 @@ x86_64-sortix x86_64-pc-sortix x86_64-twizzlerx86_64-pc-twizzler x86_64-unknown-ptx x86_64-sequent-ptx x86_64-windows x86_64-pc-windows +x86_64-windows-gnu x86_64-pc-windows-gnu +x86_64-windows-msvcx86_64-pc-windows-msvc x86_64-wrs-vxworks x86_64-wrs-vxworks x86_64-wrs-vxworks-simlinuxx86_64-wrs-vxworks-simlinux x86_64-wrs-vxworks-simwindows x86_64-wrs-vxworks-simwindows -- 2.40.1
Re: [PATCH] config.sub: Accept LLVM-style `$cpu-$vendor-windows-{gnu, mingw}`
For the record, this came out of https://github.com/NixOS/nixpkgs/pull/235230. I am one of the original/main authors of Nixpkgs/NixOS's platform specification system, and also a few years back contributed a major refactor/systematization of GNU config. (Look no further than the recent 63acb96f92473ceb5e21d873d7c0aee266b3d6d3 which fixed a spelling of mine. Sorry!) It has been a long, slow project of mind to slowly nudge all the major platform specification systems in the world towards each other and a more systematic middle ground. This could be considered another small step in that journey. I have yet to investigate but my co-contributor who authored that pull request may have also found some bugs in GNU config too. We'll be happy to submit patches if so. John On Mon, Jun 26, 2023, at 7:56 PM, John Ericson wrote: > In older times, MinGW (GCC toolchain with modified windows headers) was > the only free software toolchain for Windows. But now, LLVM has > excellent support both for MinGW ABI and Microsoft's own. (The > distinction matters for C++ more than C.) > > LLVM[1], Rust[2], and other projects have taken to differentiating these > two as `...windows-gnu` vs `...windows-msvc`. I think that makes a lot > of sense, as it correctly identifiers both their commonalities and their > differences. > > A lot of MinGW-supporting software, most notably GCC itself, will > presumably continue to use configs like `x86_64-pc-mingw32` and > `i686-pc-mingw32`. That's fine; this patch doesn't normalize them away > (like LLVM does) or remove them! If and when that software wants to > support the MSVC ABI without requiring MSVC itself, they can switch to > these newer configurations. > > [1]: > https://github.com/llvm/llvm-project/blob/a18266473be1439d324059afa0e8b124f0466428/llvm/unittests/TargetParser/TripleTest.cpp#L1907-L1951 > > [2]: > https://github.com/rust-lang/rust/blob/36fb58e433c782e27dd41034284e157cf86d587f/compiler/rustc_target/src/spec/mod.rs#L1255-L1271
[PATCH] config.sub: Accept LLVM-style `$cpu-$vendor-windows-{gnu, mingw}`
In older times, MinGW (GCC toolchain with modified windows headers) was the only free software toolchain for Windows. But now, LLVM has excellent support both for MinGW ABI and Microsoft's own. (The distinction matters for C++ more than C.) LLVM[1], Rust[2], and other projects have taken to differentiating these two as `...windows-gnu` vs `...windows-msvc`. I think that makes a lot of sense, as it correctly identifiers both their commonalities and their differences. A lot of MinGW-supporting software, most notably GCC itself, will presumably continue to use configs like `x86_64-pc-mingw32` and `i686-pc-mingw32`. That's fine; this patch doesn't normalize them away (like LLVM does) or remove them! If and when that software wants to support the MSVC ABI without requiring MSVC itself, they can switch to these newer configurations. [1]: https://github.com/llvm/llvm-project/blob/a18266473be1439d324059afa0e8b124f0466428/llvm/unittests/TargetParser/TripleTest.cpp#L1907-L1951 [2]: https://github.com/rust-lang/rust/blob/36fb58e433c782e27dd41034284e157cf86d587f/compiler/rustc_target/src/spec/mod.rs#L1255-L1271 --- config.sub| 11 +-- testsuite/config-sub.data | 2 ++ 2 files changed, 11 insertions(+), 2 deletions(-) diff --git a/config.sub b/config.sub index f6ede1d..f7e93ce 100755 --- a/config.sub +++ b/config.sub @@ -145,7 +145,8 @@ case $1 in nto-qnx* | linux-* | uclinux-uclibc* \ | uclinux-gnu* | kfreebsd*-gnu* | knetbsd*-gnu* | netbsd*-gnu* \ | netbsd*-eabi* | kopensolaris*-gnu* | cloudabi*-eabi* \ - | storm-chaos* | os2-emx* | rtmk-nova* | managarm-*) + | storm-chaos* | os2-emx* | rtmk-nova* | managarm-* \ + | windows-* ) basic_machine=$field1 basic_os=$maybe_os ;; @@ -1766,7 +1767,7 @@ case $os in ;; none) ;; - kernel* ) + kernel* | msvc* ) # Restricted further below ;; *) @@ -1785,6 +1786,8 @@ case $kernel-$os in ;; managarm-mlibc* | managarm-kernel* ) ;; + windows*-gnu* | windows*-msvc*) + ;; -dietlibc* | -newlib* | -musl* | -relibc* | -uclibc* | -mlibc* ) # These are just libc implementations, not actual OSes, and thus # require a kernel. @@ -1799,6 +1802,10 @@ case $kernel-$os in echo "Invalid configuration '$1': '$kernel' does not support '$os'." 1>&2 exit 1 ;; + *-msvc* ) + echo "Invalid configuration '$1': '$os' needs 'windows'." 1>&2 + exit 1 + ;; kfreebsd*-gnu* | kopensolaris*-gnu*) ;; vxworks-simlinux | vxworks-simwindows | vxworks-spe) diff --git a/testsuite/config-sub.data b/testsuite/config-sub.data index 3b622ab..bb19dc2 100644 --- a/testsuite/config-sub.data +++ b/testsuite/config-sub.data @@ -865,6 +865,8 @@ x86_64-sortix x86_64-pc-sortix x86_64-twizzlerx86_64-pc-twizzler x86_64-unknown-ptx x86_64-sequent-ptx x86_64-windows x86_64-pc-windows +x86_64-windows-gnu x86_64-pc-windows-gnu +x86_64-windows-msvcx86_64-pc-windows-msvc x86_64-wrs-vxworks x86_64-wrs-vxworks x86_64-wrs-vxworks-simlinuxx86_64-wrs-vxworks-simlinux x86_64-wrs-vxworks-simwindows x86_64-wrs-vxworks-simwindows -- 2.40.1
