Yes, we are very concurrent with Cygwin. We have a modern Github-centric approach to software development and use ArchLinux's Pacman so like them are a rolling software distribution.
We hope that other software projects will use us as their library provider and build enviornment on Windows, as that way it should be easier for them to also keep up to date.
Unlike the old MSYS, we are also 64-bit and that allows using --enable-auto-image-base which means no more needing to rebase your DLLs. Also, Cygwin have made great strides over the many years since MSYS forked from them and it is now both much faster and more standards compliant.
Git-4-Windows is also based on MSYS2 now and some day (hopefully soon) we will fully merge their work (a lot has been merged already) and use their native git executable.
Sorry for the basic questions, but the github page (and SourceForge page) aren't answering all of my beginner's questions...
If Msys2 is Cygwin-derived, does that mean all packages in the Msys2-Pacman are all Cygwin packages? I.e., making this "Cygwin with Pacman as a package manager?"
Does this also mean Msys2 packages can never be more current than Cygwin packages (not that this is a bad thing, but as far as I know Python3 in Cygwin is still < 3.5).
Is the benefit of Msys2 that some packages could be native windows builds instead of Cygwin-dll reliant packages?
Is there some more documentation on how msys2 relates to mingw somewhere? I recently came across msys2 when half-heartedly trying to compile Darktable[1] for windows 10.
As far as I can tell, msys2 is still posix/GNU for windows, with alternate shell (bash, not powershell etc) and alternate filesystem (posix/gnu-like)? While mingw is/was gnu/posix binaries for windows.
Both have their place -- but I'd be really happy if something akin to msys2 was available more like mingw -- so I could use the (now finally quite usable) standard windows command line along with (hopefully) MS compilers and have some hope of compiling stuff that uses automake etc.
As far as I can figure out, msys2 doesn't (try to) help with that? It's more like a GNU chroot that runs under windows? In which case most/many use-cases might be better served with a vm under VirtualBox/hyper-v[2] and/or a true "native" windows port?
Not meant as criticism of the project, I'm just trying to figure out if I've understood the focus of msys2 correctly.
Finally, for those wishing for "more GNU" on windows, one of the most pleasant discoveries I've made, is the scoop package manager:
[2] Especially if/when Vagrant works out of the box with hyper-v -- I'm not quite clear on the current status, but looks like it's been enabled and is included in default Vagrant now: https://www.vagrantup.com/docs/hyperv/index.html
> As far as I can tell, msys2 is still posix/GNU for windows, with alternate shell (bash, not powershell etc) and alternate filesystem (posix/gnu-like)? While mingw is/was gnu/posix binaries for windows
The M in MSYS2 stands for Minimal. Meaning the Cygwin-y part is as small as is necessary to run a shell, bash and autotools to configure and build native Windows software that links to msvcrt.dll with no dependency on the Cygwin derived msys-2.0.dll what-so-ever.
Ok, thank you for the reply. Is there some more documentation on building "complicated" packages somewhere?
Eg. for darktable, one needs libgtk+ and intltool -- as well as a xslt library -- perhaps there's a quick way to leverage what's already done for Arch[1] when attempting to build on windows?
Note, I'm not necessarily expecting such a build to work perfectly -- but if one could at least get to the point where any build-failures where in the darktable source, not from missing essential dependencies -- that'd be a start :-)
> The software built from the recipes here: (...)
So, if I understand correctly, one installs msys2 from the exe-installer, then updates the system with pacman -- and installs packages one wants from the ones in mingw-packages... and then those packages/binaries should/can be added to the normal windows path?
And that last bit one has to do manually? (Lets say I just want grep.exe and sed.exe in my path for example)?
The documentation (once you've read about pacman, and makepkg on the wiki or on Arch Linux's wiki) is in the PKGBUILD files. Building all packages should be done with the exact same command, so there's not really any different documentation for "complicated" packages. Just emit:
makepkg-mingw -s (*)
.. the complication is in the recipes and patches (which hopefully end up being upstreamed, but not often enough).
Darktable won't work without a good amount of effort as AFAICT, no one's built it for Windows. We have most of the dependencies though.
You'd install MSYS2, then pacman -S base-devel and mingw-w64-{x86_64,i686}-toolchain, then not install anything else (*). The -s here means "sync dependencies", sync is pacman speak for install, more or less. By setting up the dependencies in the PKGBUILD correctly, and adding -s to the makepkg-mingw command, you guarantee that you've got it correct for when people install the binaries when it gets to that stage, and that the CI systems fetch the right dependencies when they try to build darktable.
Don't add anything to your Windows PATH. Ever. Why would you break other software by having it run MSYS2 software by mistake? I've never understood software that presumes to add itself to the Windows PATH. Particularly without asking. Really, just what? We don't even ask. When you run our shells we add you to the PATH during that session.
Anyway, that's my global Windows PATH rant over.
I guess that's the bit you didn't get. To use MSYS2, don't use cmd.exe or powershell. Instead, run msys2_shell.bat (to use makepkg_mingw or makepkg), mingw64_shell.bat or mingw32_shell.bat, accept the ways of and use the mintty terminal.
Next you would convert the following PKGBUILD from Arch Linux:
.. to MSYS2/mingw-w64 form (look at the roughly 1000 references in MINGW-packages), use pacman -Ss to find the equivalent package name, use makepkg-mingw -s to test.
If I'm understanding it right, this is fantastic! I'm very happy using pacman and AUR with Arch, and having analogous resources for MSYS opens up a whole world of possibilities for running good software on Windows.
Right. Then I think I had the right idea (of what MSYS2 is/aims to be). I was sort of hoping it was less self-contained - and more integrated with the windows-side.
I hope you misunderstand slightly still. So msys2 executables - those linked to msys-2.0.dll can be run from Windows executables (or double clicked to launch from Windows Explorer, or pinned to the Start Menu or the Task Bar), for example, you can tell TortoiseGit to use MSYS2's git.exe and it'll work quite well, or Qt Creator to use msys2's msys-2.0.dll linked gdb.exe (as opposed to our mingw-w64-{x86_64,i686}-gdbs that are not). I went to some lengths to make that stuff work correctly. The same applies to MSYS2's mingw-w64 executables.
Both types of executable can also be run from from PowerShell or cmd.exe too of course. In very few cases you may need to add the correct "bin" folder to your PATH before you do so.
If you want to build MSYS2 packages using the build system we've adopted, then you need to use our shell. That is all (and a reasonable requirement).
You can't link (at the C/C++ level) msvcrt.dll linked-executables with Visual Studio > 6.0 executables / libraries and expect things to work properly for anything but the most trivial cases.
These aren't things that MSYS2 imposed though, these are just the realities of inter-operation between GCC and MSVC as they stand at present.
Thanks for answering! I'll have to check it out. Fortunately I don't spend much time on windows these days, and I had switched to babun from msys because of so many deficiencies in their old cygwin fork.
One thing I do like about msys over cygwin is that compiled binaries don't have a dependency on a dll. If msys2 is using cygwin libraries, does it have the same dependency?
Yep, but those tools rely on a DLL (msys-1.0.dll or msys-2.0.dll,) which is Cygwin by another name. MSYS is not MinGW. Programs like Bash will never run under MinGW because they rely on things like fork(), which are only provided by Unix, Cygwin, or a Cygwin fork like MSYS.
.. ish, there are significant differences. In terms of amount of code, minor, but in terms of behaviour, not so. Mainly, when msys-2.0.dll detects it is calling a native program it translates any arguments that look like paths to Windows form. The same is true for some specific environment variables.
Indeed, we really want people attached to or passionate about the projects we provide packages for to jump on board. There's loads of interesting work to do, so please consider rolling your sleeves up.
vim configs are often different per-platform anyway. I have an if mac/else block in my gvimrc, since gfn, for example, requires "Font:hSize" on OS X and another type of font selector on Linux-based systems. Things like that are not really new.
