On 9/18/23 10:57, Po Lu wrote:
John Ericson <l...@johnericson.me> 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
