-
Notifications
You must be signed in to change notification settings - Fork 40
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 an example for how to use the github action with CMake #149
Conversation
Somewhat related, there was talk about changing the default cmake generator to Ninja in our build. Do you think that's a good idea? |
I guess it could be, because the default one, which ends up looking for MSVC even outside of I wonder if "MSYS Makefiles" would be the least surprising default, for unix projects that would do just |
Is it correct to reflect ucrt and clang build matrix in docs? Those are somewhat considered as testing area now.
I forgot the package name but if I change MSYS Makefiles to Ninja then CMake can not find wxWidgets as dependency. |
yeah, likely less surprising, even if slower... thanks Ideally we want people to use ninja though (to get rid of the cygwin dependency) and changing it from make to ninja after the fact will likely result in some breakage. |
I would definitely advertise them here. This is for the case when you want to test building your own project and just want to have the bare toolchain available from msys2. If one builds a project and adds commands for installing specific packages that don't exist, then that'll probably be pretty clear to the user what happened. (But a link explaining what the different msystem options are would be good - I'll add one.)
Yeah, for actual practical compilation, ninja clearly is the best. Maybe it's better to push for people to use that and make it default - it's not worse than before anyway (either you manually set the generator, and/or build using |
This shows off a couple aspects; how to install the tool packages with the right prefix (as you need the mingw version of CMake, not the msys version), how to set a non-default project generator, and mentions another gotcha from the generic GitHub Actions CMake example/template.
Please, let this kind of disruptive PRs alive for at least 24-48h before merging, so that maintainers/contributors can provide feedback, should they want and have time to. In this case, I do not agree with adding this content to the main readme. We don't want to overload the readme with specific workflow examples for particular use cases. I do acknowledge that the information contributed by this PR is relevant and it should be available in the docs of MSYS2 as a whole, but it does not fit where it was written. Precisely:
strategy:
matrix:
include:
- { sys: mingw64, env: x86_64 }
- { sys: mingw32, env: i686 }
- { sys: ucrt64, env: ucrt-x86_64 } # Experimental!
- { sys: clang64, env: clang-x86_64 } # Experimental!
steps:
- uses: msys2/setup-msys2@v2
with:
msystem: ${{matrix.sys}}
install: mingw-w64-${{matrix.env}}-toolchain
I don't feel like reverting this PR, because it is not a critical issue. However, I would be glad if a follow-up PR addressed those concerns. EDIT FTR, https://github.com/msys2/setup-msys2/commits/egs |
ok, sorry, I'll keep that in mind. |
Thanks for picking up the ball regarding moving the info to the right locations! I’m a little unavailable at the moment, but I’ll try to help out with what’s left to do when I have a bit more time again. |
@mstorsjo no rush! I created msys2/msys2.github.io#144 for tracking that enhancement. |
I've created msys2/MINGW-packages#9176 for changing the default to ninja |
This shows off a couple aspects; how to install the tool packages
with the right prefix (as you need the mingw version of CMake, not
the msys version), how to set a non-default project generator,
and mentions another gotcha from the generic GitHub Actions CMake
example/template.