Hacker News Reader

Comment by RayDonnelly | Hacker News Reader

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.

View on HN

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?

This has been answered before.

No, the msys2 repo doesn't follow the Cygwin packaging versions or schedules at all. They are built from the recipes at: https://github.com/Alexpux/MSYS2-packages

.. they link to msys-2.0.dll which is Cygwin derived and are thus GPLed and exist to provide a POSIX-y shell and build tools to allow building:

https://github.com/Alexpux/MINGW-packages

.. which are full of native Windows software under various licenses.

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:

http://scoop.sh/

[1] http://www.darktable.org/install/

[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.

The software built from the recipes here:

https://github.com/Alexpux/MINGW-packages

.. does not link to the GPLed msys-2.0.dll. It is built with mingw-w64 GCC. The focus of the project is to expand that collection of software.

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)?

[1] http://redmine.darktable.org/projects/darktable/wiki/Buildin...

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:

https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=darkt...

.. 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.

Good luck. Join #msys2 on OFTC to ask for help.

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.

Great. MSYS2 please though.

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.

Thank you for the detailed reply.

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.

> I hope you misunderstand slightly still.

Maybe I did :-)

Thank you for all your detailed answers.

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.

Babun brings nothing to the table. I hate what they did to the apt-cyg copyright notices. Bad behaviour.

Reply on news.ycombinator.com