Move the build environment closer to Cygwin

[lazka]

Because there hasn't been an issue about this, just chat in various places, a short summary:

We want to move closer to cygwin, in short, msys should no longer be a thing you target, just a slight variation of cygwin.

Done:

• libtool defaults to "msys-" prefixes even for cygwin, so we can build for cygwin libtool: override the soname_spec for cygwin as well #2779
• We are dropping various autotools build system patches by setting a cygwin target triplet, like db: drop msysize patch #3004, icu: drop msysize patches #2982 etc.
• Python now pretends to be running on cygwin python: pretend to be cygwin in more places #2496
• meson always only reported cygwin (initially patched, now inherited from Python)
• CMake was changed to pretend to be running under cygwin: cmake: Simplify MSYS support patch #2422
• Make uname pretend to run under cygwin via MSYSTEM=CYGWIN: uname: allow setting the system name to CYGWIN msys2-runtime#97

To do:

• Remove all msysize patches
• Change the default triplet to cygwin
• Respect the CYGWIN env vars in the runtime as a fallback: Fall back to CYGWIN env var if MSYS isn't set msys2-runtime#70
• Change the DLL prefix from "msys-" to "cyg" (unclear if we should do this...??)

Overall Goals/Strategy:

• Share as much as possible with cygwin
• Make cygwin documentation apply to msys where possible
• In cases where possible and needed allow users to still detect msys in addition to cygwin

[mati865]

What about GCC and binutils?

Less patching because of:

Change the default triplet to cygwin

[angelog0]

What would be the difference between MSYS2 an CYGWIN? Why an user should continue to use MSYS2 and not Cygwin which has many more packages and allows also to run X apps? Why do not rename MSYS2 to CYGWIN2, then? Would the only difference that MSYS2 uses pacman and Cygwin setup.exe? or you are thinking to reintroduce also setup.exe in place of pacman? Please, destroy something that works and is original..

NO, I do not concord with above choices.

[mati865]

@angelog0 note this change affects only MSYS environment (/usr).
Our goal is still the same: provide users with means to build native applications/libraries.
This is sort of opposite of Cygwin where AFAIK everything runs with their POSIX emulation layer.

So for the end user everything related to installation and native compilation (all subsystems other that MSYS) remains the same. For maintainers however it means less effort to keep POSIX emulated things working.

[angelog0]

@mati865, I understood this

this change affects only MSYS environment

but Cygwin has a lot of mingw* packages and if they would, they could produce the same native apps as you. A that point, MSYS2 would be the bad copy of Cygwin, bad because MSYS2 lacks X-apps...

Yes, preserving originality could cost...

In any case, do your best.

[mati865]

Yes, preserving originality could cost...

What do you mean?
MSYS2 runtime is just Cygwin runtime with a bit over 30 patches atop it. Target triple is basically the same except the name and linked libraries.

There is no a lot of originality here, MSYS subsystem always have been Cygwin with some patches and different name.

[goyalyashpal]

hi, i am an end user. will it make msys any more heavy? will it affect performance?

as i dont use msys2 for building, i use it (bash and all the coreutils etc) as my default shell and like i am using these as my main system and do all my tasks on it. so....

[Biswa96]

In ideal situation, no one should feel any change in normal usage. This change should be transparent to every users.

[sskras]

@mati865 commented on May 30:

There is no a lot of originality here, MSYS subsystem always have been Cygwin with some patches and different name.

... and a nice package manager:)

[sskras]

@angelog0 commented on May 30:

but Cygwin has a lot of mingw* packages and if they would, they could produce the same native apps as you. A that point, MSYS2 would be the bad copy of Cygwin, bad because MSYS2 lacks X-apps...

Well, if you seek for something different than Cygwin, but still would like to run X11 apps (and of course use POSIX-like interfaces), I suggest you to join midipix project:
https://sysdeer.net/
https://www.midipix.org/

Though I am not sure how well the X11 apps works after they are build on midipix. I have made my first build only a few days ago, and still haven't managed how to run it.

@yashpalgoyal1304 commented 4 hours ago:

hi, i am an end user. will it make msys any more heavy? will it affect performance?

as i dont use msys2 for building, i use it and all the coreutils etc as my default shell and like i am using these as my main system and do all my tasks on it. so....

Same here. I invite you too to try the aforementioned midipix project.

It has no fancy installer yet, and there are two repositories (out of 36 in total) that are being opened to the user only on direct request in person. So, it's still young project, but gives me a sense of the right solution for such tasks (and even some thrill):
https://dev.midipix.org/build/midipix_build

[goyalyashpal]

also, so, how will this take place on my end.

like will it be delivered by some package update? or will i have to do a reinstall? i am asking as i only see these 3 msys packages installed, and only msys2-launcher seems to be one which might be related to this.

$ pacman -Q | grep msys
msys2-keyring 1~20210904-1
msys2-launcher 1.5-1
msys2-runtime 3.3.5-2

---

@sskras thanks for the info, i will look into it. but i am a newbie and most of the time i cant get stuff to work 😅 . so... but yeah, i will see...

---

Addition (2022-12-26): the uname -a reflects msys2-runtime

[Biswa96]

Users don't have to do anything. The msys2 packages that you've mentioned were present since th beginning. See this page for any futher info about those packages https://packages.msys2.org/search?t=pkg&q=msys2

[lazka]

There is now a Cygwin mode for uname:

$ uname -a
MSYS_NT-10.0-22000 desktop 3.3.5-341.x86_64 2022-07-04 21:33 UTC x86_64 Msys
$ MSYSTEM=CYGWIN uname -a
CYGWIN_NT-10.0-22000 desktop 3.3.5-341.x86_64 2022-07-04 21:33 UTC x86_64 Cygwin

[lazka]

just for the records and bookkeeping, foll is the output on my system:

this is not the newest version (see uname -v)

[goyalyashpal]

$ uname -v                              #  -v, --kernel-version     print the kernel version
2022-05-30 21:10 UTC

---

update:

so, i did update pacman -Syu (and by default, it did core system update of filesystem and msys ---- something; rerunning it was asking for full system update, which i denied), and now, instead of mingw64, it is showing cygwin in the front, but on the end, it's still showing msys like before

$ uname -a
MSYS_NT-10.0-19042 LAPTOP 3.3.5-341.x86_64 2022-07-04 21:33 UTC x86_64 Msys

$ MSYSTEM=CYGWIN uname -a
CYGWIN_NT-10.0-19042 LAPTOP 3.3.5-341.x86_64 2022-07-04 21:33 UTC x86_64 Msys

---

update2:

i had completed the full system update too, and now, it is shown cygwin in the end too:

$ uname -v
2022-07-04 21:33 UTC

$ uname -a
MSYS_NT-10.0-19042 LAPTOP 3.3.5-341.x86_64 2022-07-04 21:33 UTC x86_64 Msys

$ MSYSTEM=CYGWIN uname -a
CYGWIN_NT-10.0-19042 LAPTOP 3.3.5-341.x86_64 2022-07-04 21:33 UTC x86_64 Cygwin

[goyalyashpal]

edit: moved to a more apt issue

[cbrt64]

Looks like ea0a844, see also CYGPORT_RELEASE_INFO in afa957a. HTH

[lazka]

If that's a problem please file an issue and we can have a look. Otherwise this seems off topic here ;)

[Kreijstal]

tbh, if this could just be cygwin with pacman +(the dev enviroments), I wouldn't complain (I would love msys2 with X) (No, cygwin has no pacman)

[goyalyashpal]

i think u forgot (or didn't notice) the msys2 path conversions i.e. no requirement of cygpath/c/... and that cygwin doesn't generate native code on compiling; so, it can't be used as a buildchain.

cygwin with pacman +(the dev enviroments), I wouldn't complain