Closed 0x00002a closed 3 years ago
It also uses an external version of spdlog (mingw-w64-x86_64-spdlog) since there was an issue when trying to fetch it via cmake.
What was the issue? To me this sounds like something very much worth figuring out now rather than later down the road. Especially as this might also happen to other dependencies that might be optionally fetched in the future such as nlohmann::json
.
I squashed the commit which had it but here: https://github.com/0x00002a/malloy/runs/2954741185?check_suite_focus=true
Failed to get the hash for HEAD:
fatal: ambiguous argument 'HEAD^commit': unknown revision or path not in
the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'
Might be something up with msys2 git?
I've actually no idea. I do use both git from MSYS2 and git installed on native Windows at times. I never ran into this before.
Any chance that this was not a clean build but had some dirt left over, especially in the _deps
directory?
That directory isn't cached so no. I too have built it just fine with embedded spdlog on msys2. this might be relevant but I'm not sure how FetchContent actually works so I'm a bit out of my depth here
I don't even have a wild guess at this point...
If we have no clue at all it might be worth trying to install git
as a regular Windows program via the official installer and dropping git
from the list of packages to install via MSYS2.
Alright that looks to have fixed it. I removed the git
download so it used the one preinstalled by default. No idea what the problem with the msys git actually was though
This adds a workflow that builds with msys2/mingw on pushes to any branch or pull requests to
main
. It currently builds with TLS ON/OFF and boost versions 1.74.0 and 1.76.0 (1.75.0 skipped because of #19). The build takes... a while. I'm not sure if thats due to usingMSYS Makefiles
rather thanNinja
or just mingw (on my machine it takes ~15 minutes to compile clean whereas msvc takes 2-3, thats withNinja
). It also uses an external version of spdlog (mingw-w64-x86_64-spdlog) since there was an issue when trying to fetch it via cmake.Closes: #27