School is ending soon, and I have slightly more time to do things. One of the things at the top of my list is adding the eZ80 as a possible toolchain for CMake.

This means that instead of having to use GNU Make for creating CE programs (along with Wine if you're not running from Windows), you'll be able to use other programs such as Visual Studio (which now has built-in CMake support!), Ninja (an alternate build system), Eclipse CDT, and Code::Blocks (accompanied by another build system) to assist in building your project.

However, I need to address some things:

What's wrong with Make?
The main problem with Make is that it's platform- and toolchain-specific. Suppose you wanted to use SDCC (Small Device C Compiler) in lieu of the official, Windows-only compiler tools: with Make, you'd pretty much have to rewrite every Makefile with the right flags to get everything to build correctly. Creating Makefiles manually is easy for the simple stuff, but the absence of a profound layer of abstraction can increase their complexity very quickly.

Why CMake?
The main reason is because CMake is proven software. It's used by a ton of reputable software projects, from Blender to KDE, and many examples of custom toolchains are available. Moreover, CMake gives you control over what generator you would like to use to create the project files.

Will this make Mateo's work obsolete?
In a short answer, no. The CMake toolchain files, which will be worked on as a separate project/repository, will work alongside the CE toolchain, but it simply will not depend on the Makefile part of the CE toolchain. Projects will just need to use CMakeFiles.txt instead of a Makefile, but the official unofficial Makefile process can still be used.

How will this improve compatibility?
This opens up the possibility of adding in SDCC support, a toolchain that can run natively on Mac and *nix without the need for Wine. I'm waiting to see whether or not eZ80 is supported, so whether or not this will happen is tentative. At any rate, I will find a way to get eZ80 to be compiled natively on non-Windows platforms.

Right now, I am working on finding paths and figuring out the best way to lay this out. The simplest design could be just a hundred lines, but the most elaborate design could be thousands, so I must choose my next steps with care.

Well, I use both CMake and Make every day (my main IDE, Clion, has cmake-based projects), but I don't see any real argument in your post... at least for the CE context.

If you look at the toolchain Makefile, for instance, it works perfectly on Linux, Mac, and Windows.

And nope, there's no eZ80 support on SDCC. It appears that you don't seem to know about Jacobly's amazing ez80 LLVM backend (also supporting z80 and z180), which will (and already does, somewhat) completely render ZDS tools obsolete, getting rid of the wine stuff for non-windows platforms, too, in addition to being lightyears ahead of Zilog things.
You can use it by building it yourself, playing with the llvmbot on EFNet's #ez80-dev chan, or with TI-Planet's Project Builder. So, strictly speaking, you can already natively compile C (and C++17, even, because why not) for the CE, it's been done (for instance, Mateo's Oiram compiled fine with LLVM, on linux).

Using CMake over Make doesn't bring any more "compatibility" to which compiler will be used in the compile->assemble->link chain. Right now, the toolchain Makefiles don't have these steps completely distinct, which makes it be a bit harder than just swapping out a variable, but eventually that's what it will be, when LLVM is working well enough, it is already planned.

By the way, regarding IDE integration on those that need CMake, we can simply just register all the source files as usual, but basically use an external build for the final steps, invoking make (I've done that already, works fine) - so the IDE is happy since the source files are all nicely defined in a target and whatnot, and you can still build with it too (calling the normal toolchain things)

All right, you win. I guess there is no room for me to contribute here, except the menial things.

Well there is no "losing" or "wining" here, and if you're more comfortable yourself with CMake than Make, nobody's going to stop you working on a CMake version of the toolchain stuff - I've just exposed a few facts that seemed important to note to answer what you said

Who knows what will happen to the build process one everything is more "stable" and "mature" (ie, LLVM stuff, a linker, etc.). Right now, we have something based on Make that works quite well, but maybe that will change...

Ideas/suggestions/feedback are always welcome, but don't lose all your motivation in building something just because one thing happened to be different than what you believed

I don't know. I'll compromise by building my projects with Make and then maybe later I'll work with CMake.