John Ericson writes:
> On 9/19/23 21:07, Po Lu wrote:
>
> Why not?
>
> I have on my hand several programs which use -winnt*, such as many old
> releases of Emacs. And users should be capable of replacing
> config.sub and config.guess with newer versions without ill effect
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-extensi
es exist, and the only one who objected against
> windows-msvc and suggested to canonicalize windows-msvc into winnt was
> Po Lu, but the arguments provided against windows-msvc were not convincing.
Why not?
I have on my hand several programs which use -winnt*, such as many old
release
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-sty
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
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
Sam James writes:
> This would make more sense if
> https://git.savannah.gnu.org/cgit/config.git/commit/?id=91f6a7f616b161c25ba2001861a40e662e18c4ad
> hadn't been merged though.
Which I've been asking to have reverted, because `msvc' is not an
operating system.
Billy Laws writes:
> I just put what MinGW was using here since that is what I'm targeting,
> I assumed that tests should represent what was actually being used.
The vendor name in configuration tuples is more or less irrelevant these
days and may be disregarded. In light of the sheer quantity
Ozkan Sezer writes:
> On 9/14/23, Po Lu wrote:
>> Billy Laws writes:
>>
>>> diff --git a/testsuite/config-sub.data b/testsuite/config-sub.data
>>> index ba934b6..aba6ffc 100644
>>> --- a/testsuite/config-sub.data
>>> +++ b/testsuite/confi
John Ericson writes:
> I used to do that, but see commit
> f0f728324021f38b0d31de399b9974535300167c : Dmitry opted to switch to
> just using Git's commit messages as the source of truth, and providing
> a make rule to generate the ChangeLog.
>
> The document you linked endorses such a choice, say
John Ericson writes:
> I had meant to just deal with windows-gnu in those 3 options,
> otherwise we have a combinatorial explosion of patches (and commit
> messages) for me to write :). Once we deal with that one we can deal
> with the others, right?
Incidentally, if you want to make it easier f
to honestly argue for each of them the best I could in the commit
> message. I know I prefer (1); I am guessing Jacob prefers (2),
> and Po Lu prefers (3).
I prefer eliminating windows-msvc too. It's also a misnomer, and we
already have *-winnt*, which represents MSVC.
Billy Laws writes:
> diff --git a/testsuite/config-sub.data b/testsuite/config-sub.data
> index ba934b6..aba6ffc 100644
> --- a/testsuite/config-sub.data
> +++ b/testsuite/config-sub.data
> @@ -102,6 +102,8 @@ arm64-apple-tvos
> aarch64-apple-tvos
> arm64-apple-tvos10.0
"Dmitry V. Levin" writes:
> Hi,
>
> On Mon, Sep 11, 2023 at 10:11:39AM +0800, Po Lu wrote:
>> Where are the config maintainers? Karl Barry and company?
>> (I don't remember his e-mail nor do I have it at hand.)
>>
>> I would expect them
"Zack Weinberg" writes:
> If you could provide me a reference to your original request (e.g. URL
> in the mailing list archive) I will undertake to get it done. If I try
> to find it myself I'm afraid I will pick the wrong thing.
>
> If there is a specific git commit or commits you want reverted,
Where are the config maintainers? Karl Barry and company?
(I don't remember his e-mail nor do I have it at hand.)
I would expect them to be actively reading this list, but instead my
original request has been left twisting in the wind.
"Zack Weinberg" writes:
> I haven't been following this long discussion very closely but I do
> have some opinions (with my "de facto autoconf maintainer" hat on):
>
> 1. As a general rule, it is not safe to change the canonicalization
> (i.e. the config.sub output) of an existing system name, *a
connor horman writes:
> It seems to me reading this thread that we've come into two
> conflicting realities: * There exists targets that need to be
> distinguished, and * They are not distinct in any component that
> config.sub has, therefore they cannot and should not be distinguished.
>
> mingw
People, the nature and widespread use of config.* precludes any efforts
aimed at ``rethinking'' the tuples they accept and generate. If you
want your own format, then by all means, proceed with your own project.
But please leave config.* in peace.
Jacob Bachmeyer writes:
> There are several GNU/Linux distributions that either use or can use
> musl libc already. (See:
> https://en.wikipedia.org/w/index.php?title=Musl&oldid=1164590075>)
> Musl libc does not have the same features as GNU libc, so it is
> rightly a different ABI target, howev
Jacob Bachmeyer writes:
> No, we are not. CPU-VENDOR-KERNEL-OS-LIBCABI, with at least one of
> the latter three omitted, fits the bill. In that case, the reference
> to MinGW means that "OS" and/or "KERNEL" are omitted and MinGW is the
> ABI. The next logical extension is to allow all five to
Jacob Bachmeyer writes:
> Then its present use is *wrong* and a bug that should be fixed.
The subject of this thread, indeed.
> It is a little more complex than that: the GNU system theoretically
> can run on any of multiple kernels. While Linux is most commonly
> used, GNU HURD is still in d
Jacob Bachmeyer writes:
> I said "with only 3-or-4-of-5 elements present"; that using all 5
> elements is currently invalid does not change that we effectively
> /have/ 5 elements, with a restriction that only 3 or 4 of them can
> actually be present in any one tuple.
>
>
> -- Jacob
And my point
"John Ericson" writes:
> I have offered multiple times to change it to windows-mingnu or
> something else. Let's not be hung up on this, it is just making a straw
> man of the broader project of making configs that are more
> consistent.
The point is, it should not contain `windows' at all, and
Jacob Bachmeyer writes:
> This is why I am arguing that we should acknowledge that the naming
> conventions have, in practice, already changed to
> CPU-VENDOR-KERNEL-OS-LIBCABI, with only 3-or-4-of-5 elements present
> at the moment.
$ ./config.sub a-b-c-d-e
Invalid configuration 'a-b-c-d-e': mo
John Ericson writes:
> I agree the GNU project is not under any such obligation, and that's
> why I proposed windows-mingw as a compromise.
Once again, what's wrong with plain mingw? Or winnt?
> It is more work for me to go make both GCC and LLVM support, but I
> rather do that than be stuck w
Jacob Bachmeyer writes:
> No: MinGW is Windows native "Win32" API while a future `windows-gnu'
> would be the GNU system's POSIX API on an NT kernel. These are *very*
> different configurations; `windows-gnu' would more closely resemble
> Cygwin.
This is not what the `x86_64-pc-windows-gnu' co
John Ericson writes:
> Thanks Jacob,
>
> That's absolutely right that Win NT supports multiple personalities
> and so all sorts of things are possible. (Indeed that is how WSL1
> worked.)
>
> MinGW stands for "Minimalist GNU for Windows" [1], and I suspect that
> is why Saleem choose windows-gnu
Jacob Bachmeyer writes:
> At this time, yes. However, the GNU utilities are designed to be
> fairly portable and the NT kernel was designed to support multiple
> ABIs, so a hypothetical port of GNU to run under MS-Windows is within
> the realm of possibility. (In fact, the underlying architectu
"John Ericson" writes:
> If Musl, GNU Libc, and Android are all different operating systems,
> why are MSVCRT, MinGW, and Cygwin not different operating systems?
Musl is not an operating system, but Musl-based systems are distinct
from GNU and Android systems, in that they share nothing in commo
Adam Joseph writes:
> Quoting Zack Weinberg (2023-08-18 04:42:32)
>> On Thu, Aug 17, 2023, at 8:34 PM, Po Lu wrote:
>> > ... such blunders should be ignored, or at least normalized...
>>
>> Even more important than this is the principle that config.sub canonical
&
"John Ericson" writes:
> In fairness I just recently submitted the patches added them, so
> absent a clear notion of GNU config releases I think a grace period
> where we can reconsider recently added changes is acceptable.
So let's please remove that change, and replace it with one that
canonic
x86_64-pc-windows-* is first and foremost a _misnomer_. The format of a
configuration triplet (or quadruplet) is set in stone:
MACHINE-VENDOR-[KERNEL-]OS.
Given that the MinGW ABI does not constitute the GNU operating system
executing on the MS-Windows kernel, and MSVC is not an operating system,
33 matches
Mail list logo
