Possibly, although you may find that CMake older than a certain release does things differently, so it partly depends on the range of possible versions you need to support. If you’ve got full control over the build environment and you can require CMake 3.16+ or 3.17+ or whatever, then if it works for you it should keep working, though I’d test hard for corner cases.
For instance, it’s possible the generated build system could operate as expected when you run make all (which is implicit in just make), but fail to trigger the right set of dependencies if you make $specific_target.
Practically the entire purpose of add_custom_command() is to generate files so that targets can depend on them. (“Generating Files” is even the section heading that covers 3/4 of the length of that command’s documentation page.) So, the official CMake position will probably be that it’s safer to write the configs to a file and set the necessary dependencies on that file, and there’s some wisdom in that.
Having add_custom_command() rules depend on the output of a previous add_custom_command() should be pretty safe and reliable. (As long as all of the necessary dependencies are in place, as you discovered.) It’s one of CMake’s core functions to manage those relationships between build rules.
But what does that first file depend on, that would ensure it’s always going to be regenerated anytime and everytime the configuration gets updated? The only files being modified during a config change, potentially, are the build scripts — relying entirely on implicit dependencies there feels a whole lot less safe.
It might work. But, probably far safer to explicitly generate a file during the build, something the first link in your dependency chain can be configured to depend on so that it’ll always get triggered to rebuild when that file is updated.
That’s my 2¢, anyway.