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.