unknownbrackets / maxcso

Fast cso compressor
ISC License
390 stars 23 forks source link

Use CMake for building #47

Closed KOLANICH closed 3 years ago

KOLANICH commented 3 years ago

The current approach for building this project is a mess. I recommend to use CMake instead. It would allow more flexibility in changing compilers and targets.

unknownbrackets commented 3 years ago

I don't see much trouble in defining CC and/or CXX, and many platforms have things like update-alternatives that will often make those Just Work. It's already very easy to compile with clang, gcc, etc. An untested compiler might not work if it's using outdated libraries, but CMake won't really fix that.

What's the tangible benefit? Outside of requiring someone to rewrite a build script in another language, and revalidate the builds on other platforms, and update the CI scripts to use cmake instead - which is just extra work - what would this fix?

For example, I suppose maxcso probably doesn't run on Hurd (but maybe it does?), though I doubt CMake would help that. I'm pretty sure it does work fine on BSD already.

-[Unknown]

KOLANICH commented 3 years ago

What's the tangible benefit?

Not so much benefit. Just a bit more versatility for which one would have to pay by having CMake on his computer. Unneeded when the environment is precisely known, but may be useful in other cases. But from the other side it may allow to have other environments without changing the sources. IDK if it worth, but for the fixing of the makefile for MinGW-w64 I had to spend quite some time. I hope that CMake would allow to automate that because it has modules for discovery of popular libs.

unknownbrackets commented 3 years ago

Hm, well, I think that's just a factor of it being a different language, essentially. Someone might say Meson or Bazel is better, or perhaps SCons. Maybe one could even use Broccoli. It seems like we have too many: https://news.ycombinator.com/item?id=16488772

The funny thing is some of these just use makefiles under the hood. Makefiles are simple and they're probably not going anywhere. I don't have to worry that a Makefile I write will have compatibility compliance warnings with a new version of Make in 5-10 years or stop working altogether - that almost certainly will be true of CMake, though.

And CMake is no magic bullet - for example, PPSSPP has some hacks for mingw compilation to work within its CMakeLists.txt. The main issue with mingw was really that libdeflate decided mingw ought to be treated differently - and it doesn't support CMake either, so if I switched I'd probably have to unwrap why they did that and make my own CMake build script for libdeflate too.

So with that and the fact that there's a Makefile that already works plenty well on macOS, BSD (though I think it requires gmake), various Linux distros, etc.... I don't really want to move to CMake without a compelling reason. Possibly if I someday decided to have a GUI in this repo (which isn't really likely) that would be easier with CMake than Make. But other than that, switching build systems entirely just has more risk than reward.

-[Unknown]