John Ericson <l...@johnericson.me> 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.
