MSYS2 is repacked Cygwin though. It is literally the same codebase compiled with slightly different flags. You need a full Unix environment for Bash to run, not just Mingw toolchain. The difference is Cygwin aims to create a full Unix system while MSYS2 just enough development environment to run bash, make etc to build native Windows programs with Mingw.
Git installs its own Mingw and Msys2 stuff but mostly compiled for a Mingw environment so they consume Windows paths natively instead of using MSYS2/Cygwin path conversion. That's why when you have mixed PATH variable all hell breaks loose with Git.
They all have to use MSVCRT or UCRT to stay compatible with other Windows programs and APIs like COM. And AFAIK nobody has developed a C library that's purely dependent on Win32 system APIs (it is possible just really hard). The difference is that Cygwin is trying to create this semi-isolated Unix environment to programs to think they are running under a complete Unix system like Wine does.
MSYS2 is there to just provide the basics so you can develop programs that are Windows native but use some of the tools that have really strong Unix dependence like shells or Make. They depend on the existence of syscalls like `fork` or forward slash being the directory seperator.
I do appreciate it as a daily user of MSYS2. However the bigger thing that enabled them is indeed Cygwin project since it unlocked the path to build things that are using strict Unix tooling. autoconf, Make, bash etc cannot run under a pure Windows environment. They are too dependent to the underlying system being a Unix. To use pacman, bash and make in MSYS2, you need msys-2.0.dll. Even they cite Cygwin's URL in the runtime package [1]. And they basically patch Cygwin to enable this [2]
Without Cygwin enabling the path, it wouldn't be possible to build GCC for Windows without completely changing its build system. It would be a DOA fork while Mingw and PE32+ support is a part of GCC nowadays.
The nice and genius part of MSYS2 is that it is there to primarily encourage you to develop native Windows software that has better cross-platform behavior rather than Cygwin alone. If Microsoft made a better, free of charge C compiler in early 2000s that is adhering to the standards better, we wouldn't probably need Mingw to build cross-platform apps. Now MSVC is still free of charge for only open source and individuals.
It was not clear what the parent commenter was addressing; I was under the impression they meant 'compile against the MSYS2 environment', which is broadly Cygwin, yes, which should not be forced onto a user.
Okay, but that just seems to be perpetuating the misunderstanding of what MSYS2 is intended for.
It gives you a *nix-like shell/dev environment and tools, but you build native software that runs on Windows systems that don’t have or need to have all/parts of MSYS2/Cygwin installed.
I built a network daemon using the MSYS2 CLANG64 environment and llvm toolchain on Windows 10.
Windows 7 x64 users could download the compiled single-file executable and run it just fine, so long as they installed Microsoft’s Universal C Runtime, which is a free download from Microsoft’s website.
I get your point. Although my point is that there is actually zero need for MSYS at all for this, even as a developer, and especially not with the 'CLANG64' environment. These binaries themselves are built to run in the MSYS2 environment This is how I cross-compile from Windows... to Windows with LLVM-MinGW[1]:
I think you have it backwards, but I may misunderstand what you're saying.
I'm certain I haven't misunderstood the point of MSYS2's CLANG64 and other environments.
> These binaries themselves are built to run in the MSYS2 environment
I'm not sure if you're referring to the toolchain binaries or the binaries one produce's with them.
The CLANG64, etc. environments are 100% absolutely for certain for building software that can run outside of any MSYS2 environment!
You can, of course, build executables specifically intended to run inside those environments, but that’s not the primary use case.
> (gci Env:PATH).Value.Split(';') | sort
I don't want to use PowerShell or Cmd.exe when doing dev stuff on Windows. I want to do CLI work and author scripts in and for modern Bash, just like I would for Linux and macOS. I want to write Makefiles for GNU make, just like...
Now, sometimes there are bumps and sharp edges you have to deal with via `if [[ -v MSYSTEM ]]; then`, similar in Makefile, cygpath conversion, template/conditional code in sources, and so on. But that's a small price to pay, from my perspective, for staying in the same mental model for how to build software.
Aren’t you thinking of Cygwin, or the MSYS2 shell (dev tooling)?
The Windows-native software you build with MSYS2 can be shipped to and run by users that don’t have anything of MSYS2 installed.
He must be thinking of Cygwin as half of this is installed when you install git ;) Git Bash, etc…
MSYS2 is repacked Cygwin though. It is literally the same codebase compiled with slightly different flags. You need a full Unix environment for Bash to run, not just Mingw toolchain. The difference is Cygwin aims to create a full Unix system while MSYS2 just enough development environment to run bash, make etc to build native Windows programs with Mingw.
Git installs its own Mingw and Msys2 stuff but mostly compiled for a Mingw environment so they consume Windows paths natively instead of using MSYS2/Cygwin path conversion. That's why when you have mixed PATH variable all hell breaks loose with Git.
> MSYS2 just enough development environment
Doesn't it come with `pacman` too?
You need to update stuff somehow. `pacman` is a beautifully simple package manager. It covers the complexity just enough without going overboard.
Yes, it’s wonderful.
A repacked Cygwin is one environment, but the default uses the UCRT from Microsoft.
They all have to use MSVCRT or UCRT to stay compatible with other Windows programs and APIs like COM. And AFAIK nobody has developed a C library that's purely dependent on Win32 system APIs (it is possible just really hard). The difference is that Cygwin is trying to create this semi-isolated Unix environment to programs to think they are running under a complete Unix system like Wine does.
MSYS2 is there to just provide the basics so you can develop programs that are Windows native but use some of the tools that have really strong Unix dependence like shells or Make. They depend on the existence of syscalls like `fork` or forward slash being the directory seperator.
I think you’re underestimating or discounting the work the MSYS2 team put into their layered environments mechanism:
https://www.msys2.org/docs/environments/
I do appreciate it as a daily user of MSYS2. However the bigger thing that enabled them is indeed Cygwin project since it unlocked the path to build things that are using strict Unix tooling. autoconf, Make, bash etc cannot run under a pure Windows environment. They are too dependent to the underlying system being a Unix. To use pacman, bash and make in MSYS2, you need msys-2.0.dll. Even they cite Cygwin's URL in the runtime package [1]. And they basically patch Cygwin to enable this [2]
Without Cygwin enabling the path, it wouldn't be possible to build GCC for Windows without completely changing its build system. It would be a DOA fork while Mingw and PE32+ support is a part of GCC nowadays.
The nice and genius part of MSYS2 is that it is there to primarily encourage you to develop native Windows software that has better cross-platform behavior rather than Cygwin alone. If Microsoft made a better, free of charge C compiler in early 2000s that is adhering to the standards better, we wouldn't probably need Mingw to build cross-platform apps. Now MSVC is still free of charge for only open source and individuals.
[1] "Cygwin POSIX emulation engine", https://packages.msys2.org/base/msys2-runtime [2] https://github.com/msys2/MSYS2-packages/tree/master/msys2-ru...
It was not clear what the parent commenter was addressing; I was under the impression they meant 'compile against the MSYS2 environment', which is broadly Cygwin, yes, which should not be forced onto a user.
Okay, but that just seems to be perpetuating the misunderstanding of what MSYS2 is intended for.
It gives you a *nix-like shell/dev environment and tools, but you build native software that runs on Windows systems that don’t have or need to have all/parts of MSYS2/Cygwin installed.
Example:
I built a network daemon using the MSYS2 CLANG64 environment and llvm toolchain on Windows 10.
Windows 7 x64 users could download the compiled single-file executable and run it just fine, so long as they installed Microsoft’s Universal C Runtime, which is a free download from Microsoft’s website.
> MSYS2 CLANG64
I get your point. Although my point is that there is actually zero need for MSYS at all for this, even as a developer, and especially not with the 'CLANG64' environment. These binaries themselves are built to run in the MSYS2 environment This is how I cross-compile from Windows... to Windows with LLVM-MinGW[1]:
[1]: https://github.com/mstorsjo/llvm-mingwI think you have it backwards, but I may misunderstand what you're saying.
I'm certain I haven't misunderstood the point of MSYS2's CLANG64 and other environments.
> These binaries themselves are built to run in the MSYS2 environment
I'm not sure if you're referring to the toolchain binaries or the binaries one produce's with them.
The CLANG64, etc. environments are 100% absolutely for certain for building software that can run outside of any MSYS2 environment!
You can, of course, build executables specifically intended to run inside those environments, but that’s not the primary use case.
> (gci Env:PATH).Value.Split(';') | sort
I don't want to use PowerShell or Cmd.exe when doing dev stuff on Windows. I want to do CLI work and author scripts in and for modern Bash, just like I would for Linux and macOS. I want to write Makefiles for GNU make, just like...
Now, sometimes there are bumps and sharp edges you have to deal with via `if [[ -v MSYSTEM ]]; then`, similar in Makefile, cygpath conversion, template/conditional code in sources, and so on. But that's a small price to pay, from my perspective, for staying in the same mental model for how to build software.
All msys2 does is give you a unified BSD experience and toolchain for compiling applications for any architecture and platform. Windows included.
There. I think that sums it up.