It's already bad enough that the developer needs to understand both target-based CMake and legacy CMake, now there need to be two more languages (slide 13) that must be understood? It's been 9 years since Modern CMake came out, and I'd estimate adoption at 50-50.
This deck does not address the drawbacks of doing this at all, and the only recognition of this problem is in "Stretch Goal: Research development of tool(s) to translate legacy CMake to new CMake language."
The current CMake language is fine. Nothing amazing, but good enough.
But every moment that I spend configuring CMake is a moment I don't spend doing something actually useful. I don't want to disparage the team's work--CMake is awesome software--but the way they see it is very different from the way typical developers see it.
This deck does not address the drawbacks of doing this at all, and the only recognition of this problem is in "Stretch Goal: Research development of tool(s) to translate legacy CMake to new CMake language."
The current CMake language is fine. Nothing amazing, but good enough.
But every moment that I spend configuring CMake is a moment I don't spend doing something actually useful. I don't want to disparage the team's work--CMake is awesome software--but the way they see it is very different from the way typical developers see it.