cmake-init VS cmake-init-gif-engine

https://github.com/friendlyanon/cmake-init This is how you do CMake properly. If you deviate from its install rules you are highly likely to do something wrong.

CMake itself is as declarative as a build systems need to be. For anything nontrivial, these "declarative" solutions all fall apart. Just use https://github.com/friendlyanon/cmake-init, learn CMake and you won't have any issues.

If you want something with a (mostly) Just Works experience then just use https://github.com/friendlyanon/cmake-init

For CMake basics check out the official "Getting started" tutorial: https://cmake.org/cmake/help/latest/guide/tutorial/index.html, as well as Introduction to Modern CMake. You can also get inspired by the CMake project generator cmake-init

You can just use https://github.com/friendlyanon/cmake-init to get a CMake + Conan C project ready to go with a short little command: cmake-init --c -e -p conan coolio

While not embedded, I have an example that illustrates what everyone else said.

If that doesn't suit your tastes, then maybe just a regular superbuild to orchestrate the dependency and hook it to your project.

This project makes use of a superbuild for its fuzzing. I think I should make another example repo that examplifies source generation specifically using a superbuild.

There is also cmake-init, which generates C projects as well. You can check one such example here, which is also the example to show how to fuzz test a CMake project.

VS is being stinky and flattens the folder tree? You can solve that as well, see this example.

Use a superproject approach if you want to have a code generator. SerenityOS moved to a superbuild structure exactly because having additional tools built in a single build simply does not work.

Use a superproject instead of vendoring like you are doing it now. Note that the changes from this commit are merely for convenience, because you don't have to setup RPATH info, but if you are developing Windows, you'll have to populate your PATH with the paths to DLLs either way.

Fuzzing: if your program takes any sort of arbitrary input and you aren't fuzzing, then you have broken software

That CMake code is terrible. Please take a look at this exmaple to see:

Well since others already mentioned sanitizers, I have an example repository that has sanitizer usage and fuzzing, among many other things.