[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Whither windows-msvc
From: |
Po Lu |
Subject: |
Re: Whither windows-msvc |
Date: |
Tue, 19 Sep 2023 08:02:39 +0800 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
John Ericson <list@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.
- Re: [PATCH] config.sub: recognise ARM64EC machine type, (continued)
- Re: [PATCH] config.sub: recognise ARM64EC machine type, Billy Laws, 2023/09/14
- Re: [PATCH] config.sub: recognise ARM64EC machine type, Po Lu, 2023/09/14
- Re: [PATCH] config.sub: recognise ARM64EC machine type, Sam James, 2023/09/15
- Re: [PATCH] config.sub: recognise ARM64EC machine type, Po Lu, 2023/09/14
- Whither windows-msvc, John Ericson, 2023/09/15
- Re: Whither windows-msvc, Po Lu, 2023/09/15
- Re: Whither windows-msvc, John Ericson, 2023/09/18
- Re: Whither windows-msvc, Po Lu, 2023/09/18
- Re: Whither windows-msvc, John Ericson, 2023/09/18
- Re: Whither windows-msvc,
Po Lu <=
- Re: Whither windows-msvc, John Ericson, 2023/09/19
- Re: Whither windows-msvc, Po Lu, 2023/09/19
- Re: Whither windows-msvc, Zack Weinberg, 2023/09/19
- Re: Whither windows-msvc, John Ericson, 2023/09/19
[PATCH] config.sub: recognise ARM64EC machine type, Billy Laws, 2023/09/15