On 9/18/23 20:02, Po Lu wrote:
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.
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
