Please support MSYS2 MINGW64 about physics3d

[VonTum]

I don't quite see what you're getting at? CMake is a build system, not a package manager. I guess FetchContent works for git repositories, so we could do imgui that way, but other than that, stuff like OpenGL can't be done easily that way.

stuff like OpenGL can't be done easily that way.

MSYS2 has packages for both Vulkan and OpenGL. You could just assume Vulkan and OpenGL are already available. I could handle the setup of these MSYS2 packages myself.

I don't quite see what you're getting at? CMake is a build system, not a package manager. I guess FetchContent works for git repositories, so we could do imgui that way, but other than that, stuff like OpenGL can't be done easily that way.

I understand your points though. So instead of replacing vcpkg with cmake's FetchContent, please provide two parallel way to handle dependencies, one is for people using VCPKG and one is for people not using VCPKG.

[VonTum]

Dependency Handling on Windows is a pain. If you want to avoid vcpkg you can download the dependencies yourself and put them into the proper folder as shown in the README. The links are in the README as well. We ourselves actually just download them too. (We don't like vcpkg either 😛)

Dependency Handling on Windows is a pain. If you want to avoid vcpkg you can download the dependencies yourself and put them into the proper folder as shown in the README. The links are in the README as well. We ourselves actually just download them too. (We don't like vcpkg either stuck_out_tongue)

If you are a MSYS2 user like me, you will find out that there are packages for most of the dependencies that ready to install via Pacman (MSYS2's package manager). The painful part is how to have the project's cmake be able to find them. Most of the time, the project insists on using their own version of the dependencies, either by fetching them manually via cmake or using vcpkg. Let me tell you a story. A project uses the Skia rendering engine, insisting on fetching it as a submodule and building it locally. MSYS2 already has a package for Skia, but even though that package was installed, the project's cmake was still unable to find and use the system's Skia. It's still trying to build Skia from source (which, of course, will not work as Skia needs to be patched to build on MSYS2).