-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add msys2/mingw to CI #33
Conversation
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 |
I squashed the commit which had it but here: https://github.com/0x00002a/malloy/runs/2954741185?check_suite_focus=true
Might be something up with msys2 git? |
I've actually no idea. Any chance that this was not a clean build but had some dirt left over, especially in the |
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 |
Alright that looks to have fixed it. I removed the |
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