RayDonnelly

I don't think thats true. Our compilers are complete pseudo-cross compilers (i.e. with binutils, glibc, kernel headers and their own sysroot) that can be both hosted on and always target CentOS6. This means software built with them will run on CentOS6 and will not, by default, pick up your CentOS6-incompatible headers and libraries in /usr/include and /usr/lib respectively.

As is (actually working, usable) clang 4.0.1 on macOS 10.9

Conda is a package manager for more than Python. It manages libraries that are shared between Python and R and other tools. This isn't possible with a purely Python-based solution.

It also does envs better than most other solutions since it will prefer hardlinks which allows environmental isolation at a very small cost in terms of disc space.

Full disclosure: I work for Anaconda Inc. where I am trying my best to make package management and scientific computing easier.

This is a terrible way to do IK. It is numerically unstable and will give vastly different solutions upon slight changes to the input. Coordinated Cyclic Descent using twist and swing quaternions give much better results:

http://www.tandfonline.com/doi/abs/10.1080/2165347X.2013.823...

Further, linking PhysX to GPL3 is not possible.

Most games developers won't touch GPL3, why not LGPL? Also should games engines really have *Player.cpp/.h files?

A better name might be hoop-jumper. If you want a POSIX shell and real interoperability with Windows, I can recommend MSYS2 instead.

Windows threw up CRC errors. I am not blaming Windows here, that would be unfair. Perhaps it was the only one that checked CRCs on read and one of the others didn't write CRCs on write.

My use case was to store many large git repo clones and MP3s.

I tried UDF for a few months on a macOS/Linux/Windows triple boot. It doesn't work reliably enough. I've switched to ext2 using e2fsd and Paragon (which I paid for) on Windows and macOS respectively. Fingers crossed.

I wish someone would port F2FS to Windows and macOS. This could be a good starting point for macOS.

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

It's too much, honestly, but I'm biased.

Ok, I don't know the level of elaboration you are asking for, so apologies if it I go too far.

FHS is just the split up at the top level into bin, lib, include, etc, share as opposed to having a folder called, e.g. MyApplication. Some people hate it, but it allows sharing libraries easily. Apple go for something of a hybrid with Frameworks. MSYS2 goes full Linux-style, even for our mingw-w64 (native) softare. "C:\Program Files\MyApplication" is the complete opposite. No sharing. No good for anyone.

Usually software is configured so that at `make install` time it will pull the DLLs of its dependencies beside its executables on Windows, so that, for example a Qt-based game would be packaged with the Qt DLLs in the same folder as the executable.

On MSYS2 we disable this code-path (ok, build-system code-path) and adopt the Linux path instead, so that our final package contains only the executable and a record to say "I also need the Qt shared libraries package version 5.5-3".

In fact, pacman doesn't allow us to make two packages with the same final files in it since it's a System Package Manager and it disallows such conflicts (unless the packages are marked as conflicting).

The other common thing you'll see with Windows software is people compiling and linking to static libraries because it's safer than DLL hell. It might be safer in that regard, but it's a security nightmare for the user (though they often can't know it), so we don't do that either. Our library packages do tend to come with static libraries, but our executables link to shared libraries by default which are also provided.

This way, when a security issue is found in a library, we don't need to update a load of packages containing executables that linked to that library statically, since none (or very few, some may slip through by mistake) do.

Great. MSYS2 please though.

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.

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

We adopt that. We buck the "Program Files" silliness, and go all-in for FHS layout and shared libraries.

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.

Yeah, but you need to be clear that it wasn't our cmake build of course.

Generally get used using, asking for and contributing to MSYS2 packages if you can. That way everyone benefits. It's not the norm on Windows, but it very much should be.

Well, we package our own software so we can work around any quirks that our system introduces, but actually generic cmake should work fairly well out of the box.

The difference will the down to path translation. We don't stick to the old MSYS rules precisely as that code was re-written for MSYS2. MSYS2_ARG_CONV_EXCL can be used to prevent specific translations from happening too.

A bug report would be appreciated anyway.

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

It seems we have a libvirt PKGBUILD but no released package. Here is the MSYS2 approach to software development, shamelessly taken from ArchLinux. Could you try this:

    pacman -Ss base-devel mingw-w64-x86_64-toolchain
    git clone https://github.com/Alexpux/MINGW-packages.git
    cd MINGW-packages/mingw-w64-libvirt
    MINGW_INSTALLS=mingw64 makepkg-mingw -s
    pacman -U *pkg*xz

.. and if it doesn't work file a ticket on: https://github.com/Alexpux/MINGW-packages/issues

.. otherwise you should have an MSYS2 libvirt.

even if it does work, file a bug asking that mingw-w64-libvert gets packaged.

You really should not mix binaries from different ecosystems and compilers. I do not know how TDM configure their compilers or how Fedora configures theirs (exception models, C++ ABIs) but it is a risky business and I caution strongly against it. All your packages should be compiled with the same toolchain.

Why would you use TDM compilers anyway? MSYS2 comes with its own: pacman -S mingw-w64-x86_64-toolchain gets you the 64-bit version.

Git-4-Windows is a great project, just with a different focus. They contribute a lot to our packages (and Cygwin) too since git (and the shell) drags in quite a lot of stuff.

I have literally no idea why you would even consider combining MSYS2 with TDM-x64 and Fedora precompiled.

Just use MSYS2. It is all that you need. Can you explain why you would do this?

I work on MSYS2, not Git-4-Windows. We come with Pacman included.

pacman -S mingw-w64-{x86_64,i686}-cmake

There's you out of the box. You might have tried pacman -S cmake which will have gotten you the msys/cmake package which is used for building the packages in the msys repo (i.e. those linked to msys-2.0.dll). Having to add the mingw-w64-.. prefix is kind of strange, but you get used to it.

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.

We need to merge our work carefully. Git-4-Windows with pacman and makepkg wouldn't work too well at present, as MSYS2 with a native git wouldn't work too well at present.

Please read the links on the linked to page. MSYS2 is a rolling software distribution providing software built with the mingw-w64 compilers.

Some of the software is Cygwin-like, but not much, only enough to distribute (and build) the native (mingw-w64) software and provide a shell.

There was a time (around Blender 2.70) when we did provide Blender packages and it did compile (of course, since all our software is built from source) but then llvm dropped JIT around version 3.5 and it became incompatible with OpenShadingLanguage.

We made a choice that we'd rather forge ahead with modern LLVM and Clang (for Rust, Clang-GCC and Julia) than hang back to support Blender. Given our very limited resources, this was still probably the right decision, however, we might have made a choice to create a special llvm35 package at that point, but we had no idea that OpenShadingLanguage would take so long to adapt to MCJIT, which the still haven't done to this day, as far as I know.

The important point here is that MSYS2 is a very open-source, limited resources project. We aren't experts in all packages, so if you are knowledgeable about llvm, OpenShadingLanguage and Blender and are interested to do so, then please help out.

For Blender, getting CUDA support into MSYS2 is probably high up on the priority list too.

midipix is a very interesting project.