Re: Whither windows-msvc
John Ericson writes: > I challenge you to find me a public project where this `winnt` is still in > use. Why is that of such importance? That it was used in the past is reason enough to retain it. > Yes Clang does define it, see > https://clang.llvm.org/docs/UsersManual.html#microsoft-extensions. If > it didn't, Clang would be failing in its goal to compile software > written for Microsoft's tools with as few modifications as possible. So it is *-*-winnt. > I have proposed a way to turn those follies into non-follies, which > would also help with this, and do so without breaking backwards > compatibility. I don't think config.sub ever made any formal > guarantees about what its output would look like anyways. I don't > think I have any more to say on this part. I recall several commitments of this nature being made here, within this thread, in the past month alone.
Re: Whither windows-msvc
Very nicely put Zack. I agree completely; this is what I was trying to discuss with Jacob earlier but much more elegantly stated. It is also what Adam was saying. Thanks for writing this, John On 9/19/23 17:58, Zack Weinberg wrote: On Mon, Sep 18, 2023, at 8:02 PM, Po Lu wrote: linux-musl is so named because there is no canonical name for a Musl-based Linux system. The "musl" represents "musl-based operating system", not merely the libc itself. Ditto for ulibc. I'm gonna push back real hard on this specific aspect of what you are saying. The terminology used by config.* was laid down at a time when it was extremely unusual for the kernel, the C library, the C compiler, and the base set of " user space" system software to be developed by four (or more!) independent organizations. It is now, IMHO, more appropriate to think of $host_os (the shell variable set by AC_CANONICAL_HOST) as specifying the part of the ABI that *isn't* defined by the ISA. (Ignoring historical inconsistencies about whether to specify ABI-relevant ISA variants in $xxx_cpu or $xxx_os.) In particular, I claim that it is correct to use "linux-musl" to describe *any* system built on top of the Linux kernel and musl libc, and similarly "linux-gnu" to describe any system built on top of the Linux kernel and GNU libc, regardless of what other software is included. In general, I claim that components of a complete system that do not affect its C ABI should not be considered *at all* in defining its canonical system name. zw
Re: Whither windows-msvc
On Mon, Sep 18, 2023, at 8:02 PM, Po Lu wrote: > linux-musl is so named because there is no canonical name for a > Musl-based Linux system. The "musl" represents "musl-based operating > system", not merely the libc itself. Ditto for ulibc. I'm gonna push back real hard on this specific aspect of what you are saying. The terminology used by config.* was laid down at a time when it was extremely unusual for the kernel, the C library, the C compiler, and the base set of " user space" system software to be developed by four (or more!) independent organizations. It is now, IMHO, more appropriate to think of $host_os (the shell variable set by AC_CANONICAL_HOST) as specifying the part of the ABI that *isn't* defined by the ISA. (Ignoring historical inconsistencies about whether to specify ABI-relevant ISA variants in $xxx_cpu or $xxx_os.) In particular, I claim that it is correct to use "linux-musl" to describe *any* system built on top of the Linux kernel and musl libc, and similarly "linux-gnu" to describe any system built on top of the Linux kernel and GNU libc, regardless of what other software is included. In general, I claim that components of a complete system that do not affect its C ABI should not be considered *at all* in defining its canonical system name. zw
Re: Whither windows-msvc
On 9/18/23 20:02, Po Lu wrote: John Ericson writes: It is defunct because using Autotools with Microsoft's own compilers basically impossible. Everything that supports Microsoft's own tools is now using CMake or Meson for that, and bypassing GNU config and the rest completely. LLVM however offers both GCC- and MSVC-style CLIs, and so it is actually feasible to combine LLVM targeting `windows-msvc` with Autotools. (Cross compiling from Unix also helps make things easier too.) This is incorrect. There are two wrapper scripts which provide Unix-compatible cc and CC, by translating its command line arguments into options understood by cl.exe. OK I take it back then, not "basically impossible". That could work. emacs gave up on that! If anyone else is still using `winnt` we'll here about it if we do a deprecation. We must not obsolete or remove a triplet that has served us faithfully for eons, as recently as a decade ago. Deprecation doesn't break anything. There is no problem with deprecation. It is just a warning saying that something is no longer encouraged. It is not our place to demand action from our users. Do you recognize how ubiquitous config.* are? Users expect to be capable of replacing config.* in any Autoconf program with their latest versions, without superfluous diagnostics or erroneous results being generated. I challenge you to find me a public project where this `winnt` is still in use. Of course, there are many private projects too. I'll furthermore take a bet that if we add a deprecation notice that no one will write an email complaining this broke their code, where if I mistaken I'll do some few-days-long drudgery task of your choice for Emacs. Everyone else that supported changing/removing `windows-gnu` like you also wrote that `windows-msvc` sounded useful and we should keep it. My point is, winnt already exists. Does LLVM define _MSC_VER? Yes Clang does define it, see https://clang.llvm.org/docs/UsersManual.html#microsoft-extensions. If it didn't, Clang would be failing in its goal to compile software written for Microsoft's tools with as few modifications as possible. You do realize that GNU config already parses "operating system identifiers" that are blatantly not operating systems, and has done so for years? "elf", "coff", "musl", "uclibc" are all currently valid examples that are blatantly not OSes; but expediently accepted as OSes in order to support certain configs. We should continue to be practical and support `windows-msvc` just as we previously supported things like `linux-musl`. linux-musl is so named because there is no canonical name for a Musl-based Linux system. The "musl" represents "musl-based operating system", not merely the libc itself. Ditto for ulibc. ELF and COFF are aberrations inasmuch as there is _no_ operating system. Neither of the foregoing conditions applies to MSVC, where the operating system is MS-Windows. Compounding all of that, this is not a court of law: the mere existence of one folly, or one adjudication made in the past, is not grounds upon which to permit more analogous mistakes to transpire I have proposed a way to turn those follies into non-follies, which would also help with this, and do so without breaking backwards compatibility. I don't think config.sub ever made any formal guarantees about what its output would look like anyways. I don't think I have any more to say on this part. John
Re: Whither windows-msvc
John Ericson writes: > It is defunct because using Autotools with Microsoft's own compilers > basically impossible. Everything that supports Microsoft's own tools > is now using CMake or Meson for that, and bypassing GNU config and > the rest completely. LLVM however offers both GCC- and MSVC-style > CLIs, and so it is actually feasible to combine LLVM targeting > `windows-msvc` with Autotools. (Cross compiling from Unix also > helps make things easier too.) This is incorrect. There are two wrapper scripts which provide Unix-compatible cc and CC, by translating its command line arguments into options understood by cl.exe. > There is no Emacs-specific story in what I wrote above. No doubt > perhaps Emacs did encounter some unique problems in addition, but > pain along these lines would affect everyone using `winnt` in this > way. These multiple better options (Autotools with LLVM, CMake, > Meson) obviate using `winnt` completely. The situations that compelled us to discontinue the MSVC build were very much particular to Emacs: the C runtime library distributed with newer versions of MSVC became incapable of running under Windows 9x, for example. > emacs gave up on that! If anyone else is still using `winnt` we'll > here about it if we do a deprecation. > > We must not obsolete or remove a triplet that has served us > faithfully for eons, as recently as a decade ago. > > Deprecation doesn't break anything. There is no problem with > deprecation. It is just a warning saying that something is no longer > encouraged. It is not our place to demand action from our users. Do you recognize how ubiquitous config.* are? Users expect to be capable of replacing config.* in any Autoconf program with their latest versions, without superfluous diagnostics or erroneous results being generated. > Use llvmmsvc or something similar, if distinguishing between > MSVC and LLVM is truly of such paramount importance. > > LLVM's `windows-msvc` *is* the real `windows-msvc`; no one is trying > to distinguish LLVM vs Microsoft's own tools in GNU config, just as > no one is distinguishing GCC vs LLVM in GNU config. We are not obliged to accept solecisms from other projects that contravene our own standards and guidelines. > Microsoft's own tools do not use GNU configs or anything like that, so > the choice of triple doesn't matter; that is why winnt was fine a > decade ago. LLVM however does support similar configs, and people > add configs to GNU configs for LLVM all the time, not just I. (For > example, the recent requests for "arm64ec" and "arm64_32" are > things that *only* LLVM supports, not GCC.) LLVM *does not > support* any `*winnt*` configs; you must use `windows-msvc` with it. > So if GNU config does not this triple and instead just supports the > likely abandoned and unused `winnt`, it is actively hostile to the one > extant free software toolchain that targets this platform. Since GNU config never previously provided for such "triplets", no existing software will be affected. > Everyone else that supported changing/removing `windows-gnu` like > you also wrote that `windows-msvc` sounded useful and we should > keep it. My point is, winnt already exists. Does LLVM define _MSC_VER? > And in any case, `windows-msvc' is a no-go: there is a dash in > between, rendering the msvc an operating system identifier. > > You do realize that GNU config already parses "operating system > identifiers" that are blatantly not operating systems, and has done so > for years? "elf", "coff", "musl", "uclibc" are all currently valid examples > that are blatantly not OSes; but expediently accepted as OSes in > order to support certain configs. We should continue to be practical > and support `windows-msvc` just as we previously supported things > like `linux-musl`. linux-musl is so named because there is no canonical name for a Musl-based Linux system. The "musl" represents "musl-based operating system", not merely the libc itself. Ditto for ulibc. ELF and COFF are aberrations inasmuch as there is _no_ operating system. Neither of the foregoing conditions applies to MSVC, where the operating system is MS-Windows. Compounding all of that, this is not a court of law: the mere existence of one folly, or one adjudication made in the past, is not grounds upon which to permit more analogous mistakes to transpire.
Re: Whither windows-msvc
On 9/18/23 10:57, Po Lu wrote: John Ericson writes: You just said it is a defunct attempt Only inasmuch as MSVC became intractable for Emacs's own purposes. It is defunct because using Autotools with Microsoft's own compilers basically impossible. Everything that supports Microsoft's own tools is now using CMake or Meson for that, and bypassing GNU config and the rest completely.LLVM however offers both GCC- and MSVC-style CLIs, and so it is actually feasible to combine LLVM targeting `windows-msvc` with Autotools. (Cross compiling from Unix also helps make things easier too.) There is no Emacs-specific story in what I wrote above. No doubt perhaps Emacs did encounter some unique problems in addition, but pain along these lines would affect everyone using `winnt` in this way. These multiple better options (Autotools with LLVM, CMake, Meson) obviate using `winnt` completely. emacs gave up on that! If anyone else is still using `winnt` we'll here about it if we do a deprecation. We must not obsolete or remove a triplet that has served us faithfully for eons, as recently as a decade ago. Deprecation doesn't break anything. There is no problem with deprecation. It is just a warning saying that something is no longer encouraged. Use llvmmsvc or something similar, if distinguishing between MSVC and LLVM is truly of such paramount importance. LLVM's `windows-msvc` *is* the real `windows-msvc`; no one is trying to distinguish LLVM vs Microsoft's own tools in GNU config, just as no one is distinguishing GCC vs LLVM in GNU config. Microsoft's own tools do not use GNU configs or anything like that, so the choice of triple doesn't matter; that is why winnt was fine a decade ago. LLVM however does support similar configs, and people add configs to GNU configs for LLVM all the time, not just I. (For example, the recent requests for "arm64ec" and "arm64_32" are things that *only* LLVM supports, not GCC.) LLVM *does not support* any `*winnt*` configs; you must use `windows-msvc` with it. So if GNU config does not this triple and instead just supports the likely abandoned and unused `winnt`, it is actively hostile to the one extant free software toolchain that targets this platform. Everyone else that supported changing/removing `windows-gnu` like you also wrote that `windows-msvc` sounded useful and we should keep it. And in any case, `windows-msvc' is a no-go: there is a dash in between, rendering the msvc an operating system identifier. You do realize that GNU config already parses "operating system identifiers" that are blatantly not operating systems, and has done so for years? "elf", "coff", "musl", "uclibc" are all currently valid examples that are blatantly not OSes; but expediently accepted as OSes in order to support certain configs. We should continue to be practical and support `windows-msvc` just as we previously supported things like `linux-musl`. The whole point of the massive other thread in spitting out KEY=value\n is so that that we can improve our categorization without any breakages, and relieve downstream projects like autotools from reverse engineering what we do. There are two choices: accept these "fake" OSes and other lies, or admit that the dash-separated format is ambiguous because sometime we do kernel-abi / os-abi not kernel-os. Let's go with the second, which can allow us to stop pretending musl, msvc, etc. are OSes internally, and share their now-corrected categorization with the rest of the world. John
Re: Whither windows-msvc
John Ericson writes: > You just said it is a defunct attempt Only inasmuch as MSVC became intractable for Emacs's own purposes. > emacs gave up on that! If anyone else is still using `winnt` we'll > here about it if we do a deprecation. We must not obsolete or remove a triplet that has served us faithfully for eons, as recently as a decade ago. And in any case, `windows-msvc' is a no-go: there is a dash in between, rendering the msvc an operating system identifier. Use llvmmsvc or something similar, if distinguishing between MSVC and LLVM is truly of such paramount importance.
Re: Whither windows-msvc
On 9/15/23 20:52, Po Lu wrote: John Ericson writes: This `winnt`is but more detritus from such defunct attempts. I would deprecate it so it no longer confuses people. (Deprecation I think is better than sudden removal.) It is not. Emacs used *-*-winnt4.0 to designate MSVC until support for the MSVC build was removed as a whole, some time in the 2010s. You just said it is a defunct attempt --- emacs gave up on that! If anyone else is still using `winnt` we'll here about it if we do a deprecation.
Re: Whither windows-msvc
John Ericson writes: > This `winnt`is but more detritus from such defunct attempts. I would > deprecate it so it no longer confuses people. (Deprecation I think is > better than sudden removal.) It is not. Emacs used *-*-winnt4.0 to designate MSVC until support for the MSVC build was removed as a whole, some time in the 2010s.
Whither windows-msvc
Note that `windows-msvc` is not supported by GCC. It is only supported by Microsoft's own proprietary tools, and LLVM. Thus, the only free software implementation of this target calls it `windows-msvc`. `winnt` I do see in config.log, but I have never seen used in the wild. I think it is just detritus from some obscure Alpha CPU thing. It is (a) untested, and (b) almost removed in 554e3feb158dbde3193c05fddec422c3c93531cd. See https://lists.gnu.org/archive/html/config-patches/2017-09/msg0.html for first message in the thread that led to that commit; In Ben's own words (in a reply to that original message): Thanks. I'm not normally inclined to remove triplets (because I find it a useful way to preserve the history!) but in this case, it's too confusing for all of these defunct attempts to do Unix on Windows. This `winnt`is but more detritus from such defunct attempts. I would deprecate it so it no longer confuses people. (Deprecation I think is better than sudden removal.) John
