On Tue, Sep 19, 2023 at 09:31:13PM -0400, John Ericson wrote: > On 9/19/23 20:19, Dmitry V. Levin wrote: > > On Wed, Aug 16, 2023 at 10:46:26AM -0400, John Ericson wrote: > > > >> In 91f6a7f616b161c25ba2001861a40e662e18c4ad I supported `windows-gnu` > >> and `windows-msvc`, but I forgot about the last one: `windows-cygnus`. > >> > > Is windows-cygnus a new name for something already supported by > > config.sub, or is it a new thing? > > > Yes, it is new name for something already supported. In particular, it > is a synonym for `cygwin`, just like `windows-gnu` is a synonym for > `mingw*`. (See > https://github.com/llvm/llvm-project/commit/edbdd2e5df8b59dac8ae5f45059407f8a79850d6 > > for the origin of those and `windows-msvc` in LLVM, all in the same commit.) > > If you mean to not accept duplicates where the original isn't > defunct/abandoned (like `winnt` is), then yes the consistent thing to do > is reject this patch too. > > On the other hand, if duplicate normal forms provided those normal forms > don't have other issues, then this patch is fine. > > I knew this duplicating, the point was for (a) more LLVM/Rust/other > tools convergence and (b) ergonomic `windows-*` grouping/case-matching. > And indeed I believe that `windows-cygnus` has no other issues; no on > objected to `windows-cygnus` as misleading the way that many (correctly) > pointed out that `windows-gnu` is misleading. However, whereas LLVM does > not recognize `winnt`, it does recognize `cygwin` and `mingw*`, so > neither of these other `windows-*` normal forms are strictly necessary > for LLVM compat, just for my dream of converging normal forms between > projects.
The issue with adding new names duplicating already supported ones is that every piece of software that handles the old name would have to be patched eventually to handle the new name as well. Of course config.sub can provide a canonicalization of windows-cygnus into cygwin if it helps. -- ldv
