skeeto / w64devkit

Portable C and C++ Development Kit for x64 (and x86) Windows
The Unlicense
2.68k stars 185 forks source link

Add CMake #71

Closed Semphriss closed 1 year ago

Semphriss commented 1 year ago

For my personal needs, I've added CMake to the Dockerfile. I thought I could share it, in case my work may be interesting for others.

Is it proper etiquette to open a PR directly, or is it preferable that I open an issue beforehand? I really like this project and I want to contribute back, but I don't want to come across as insisting.


Regarding the code itself, there's a small detail I'd like to specify:

There are two ways to configure CMake before building: with another build of CMake, or with a bootstrap script. The bootstrap script doesn't support cross-compilation, so I had to install CMake with apt to cross-compile CMake to Windows. I could also compile CMake from source locally, using the downloaded source code and the bootstrap script, then use that build to cross-compile CMake afterwards. It would be cleaner, but it would increase the build time. If this PR sounds interesting, which option would be preferable?

skeeto commented 1 year ago

Thanks for sharing your change, Semphriss. I'm excited you were able to leverage w64devkit for your own purposes, and this is exactly one of the use cases I had in mind. Hopefully other people will find this useful.

Opening a PR like this is perfectly fine. The potential issue would be that the project doesn't want the feature/fix/etc. and you've wasted a lot of your time developing it, which could have been avoided with a bit of advance discussion. However, these changes are already personally useful to you, and so nothing is wasted. You're just sharing something already useful.

That being said, I'm uninterested in distributing CMake in w64devkit. The kit is my curation of essentials for effective software development on and for Windows, and I personally consider CMake use a mistake. There are much simpler ways to solve the problems it's intended to solve, and it's not so great at solving those problems anyway. Due to poor defaults — no compiler warnings, -g instead of -g3, no sanitizers, etc. — it's not even good for beginners, and I see beginners repeat the same rudimentary mistakes again and again when using CMake. (Yes, if you can find the knobs then you can turn these things on, but it's difficult and far from default.)

On the positive side, the CMake project itself provides a decent "zip" distribution that works well with w64devkit. Put its bin/ in your PATH, probably via your .profile, and it fits in naturally. I've used it this way to build projects using CMake.

My feedback if I were interested in accepting these changes:

It should be fine to leverage Debian CMake for the cross-compile. I don't use Debian Mingw-w64 because when I had tried the resulting toolchain was contaminated. Bootstrapping GCC through a matching toolchain has better results. I don't expect this to matter for CMake. To check, build it both ways and then look for differences.

I sort SHA256SUMS, mainly because I keep all the source tarballs in a directory and on upgrades I update it with a brute force recompute: sha256sum * >../src/SHA256SUMS

Semphriss commented 1 year ago

Thanks for the feedback! Indeed, I'm currently using a combination of cmake, git, gpg, and w64devkit, all xcopy'ed together in a single root. But I thought it would be cool to compile as much as possible from source :)

I checked if compiling a host CMake from source would make a difference with using Debian's default one, but they give the exact same output executable, so indeed it would be simpler and faster to just use the Debian build.

I'll close this PR, but it'll be there if someone is interested in adding CMake to their builds.