I found it very boring to write CMakeLists.txt for each project, so I created my own build system Zyn, you can study it at https://github.com/zyntraxis/zyn
It is an entertaining but very silly text; metaphor and exaggeration have no place in a legal document.
Taking what is clearly expressed at face value it is a very restrictive license, e.g. "Unless you have received prior *written and signed authorization*".
Advanced GCC command line options seem hardcoded, e.g. "-fomit-frame-pointer -march=native -flto " and many more in runner.cpp.
It's probably a good fit for the author's needs, but for most other potential users running a more generic project skeleton generator or simple ad hoc script, leveraging a mature build system, is likely to do more and allow future growth for a similar effort.
You need a clear vision for what you have written the first version of.
Covering the foreseeable needs of your own typical projects, with enough configurability to handle the variations you expect, is quite the opposite of offering general purpose abstractions and models like Make or CMake: not only designing for yourself vs. designing for the public, but prioritizing completeness (an opinionated solution to build your own projects with minimal manual effort) or generality (a tool that can be used for many different projects, ideally handling any C or C++ compilation job at the cost of specifying what to do explicitly).
In the first case, hardcoded GCC options are good enough until you need something more sophisticated; in the second case, hardcoded GCC options severely limit the potential users.