CMake

[SamuelMarks]

#3 was from over 3 years ago, so thought I'd restart the conversation.

Can probably contribute CMake support myself for y'all. Main advantages:

• IDE integration;
• CPack support (build packages for many platforms);
• Cross-platform configuration & building (cmake), testing (ctest, cdash), packaging (cpack)

…and, along with vcpkg—or I suppose any package manager + pkg-config or what-have-you—one can:

• Decouple dependencies from this repo (e.g., to test with different version combinations);
• Support dependencies cross-platform

PS: I note your interest in supporting FreeBSD. That shouldn't be too difficult, particularly with this PR. Ditto for macOS. As for Windows, that'll be a more complex contribution… see my https://github.com/redis/redis/issues/9728

[JohnSully]

I've grown to lake the vanilla make scripts. I've found make is supported well by a VS Code plugin. X-Plat building is an interesting use case not well served by Make though so that is a potential spot for improvement.

The issue with the BSDs is we don't have a CI workflow for them and so we keep introducing build breaks. It's not a problem with the Makefile itself.

Is there a specific task/workflow you want to enable with this?

[SamuelMarks]

Hi @JohnSully, thanks for your rapid response.

So the main use-cases I want to support are:

• Cross-platform configure
• Cross-platform build
• Cross-platform test
• Cross-platform packaging

…in terms of FreeBSD in a CI workflow, there are plenty of solutions. See my CI runners for macOS, Windows, Linux, SunOS (GitHub Actions) and FreeBSD (Cirrus CI) @ https://github.com/offscale/c89stringutils

CMake simplifies a bunch of these processes, particularly in terms of porting to new platforms.

BTW: I like how you enable MALLOC to be provided as an arg, I was going to contribute that to redis itself a-g-e-s ago but got distracted building a cross-platform package manager for Redis.

[JohnSully]

Hmm, I do think with RocksDB the benefit of cmake becomes more obvious. Can this change co-exist with the existing make workflow? I could merge it as an experiment to see how well it works vs our old way assuming the two can co-exist.

We can make the determination on what we'll stick with at the end of the year as two build systems will be super confusing longer term.

[SamuelMarks]

Ouch:

This branch is 1 commit ahead, 14235 commits behind Snapchat:main

Merging latest, should be able to resolve issues next weekend

EDIT - Maybe you can change what HEAD this PR popints to, as it's now trying to merge 10,000 commits?!