cmake code generator language

In our C++ project we use something similar to google’s protocol buffers.
That consists of a compiler and a source file, when the compiler runs the source generates a C header (optionally a C source) that later is used in the build.
This source file can have includes, basically it needs to be rebuilt every time the source, the compiler or the included files change.
Today we implement this using add_custom_command, but it only partially works. There is no easy way to automatically get the dependencies and to link those with the C files.
How could this be improved? Maybe have the protobuf be a new cmake language (where we could use target_include, where it could automatically call the compiler to get a list of dependent files… ).
I am open to anything if there is an example or some sort of path to follow.

Thank you very much,

With more modern CMake versions (3.21), custom commands can now specify that they work with depfiles in all of the major generators. If your tool can output that, it will be scheduled to rebuild as necessary.

Thank you for the reply! Just to clarify, I got this section from the cmake online documentation:


New in version 3.7.

Specify a .d depfile which holds dependencies for the custom command. It is usually emitted by the custom command itself. This keyword may only be used if the generator supports it, as detailed below.

New in version 3.7: The Ninja generator supports DEPFILE since the keyword was first added.

New in version 3.17: Added the Ninja Multi-Config generator, which included support for the DEPFILE keyword.

New in version 3.20: Added support for Makefile Generators.

Some things there are not clear to me, for example:

  • should the depfile be created in a separate call or in the same call that creates the output file the custom_command generates?
  • Is there a description of the file, or just simply whatever a C compiler would generate for dependencies (I think it was a flat list of files)

Thank you,

The format is makefile-like I think with a output: in1 in2-like syntax. But I agree that the docs should probably expand on what the .d depfiles look like.

This worked like a charm, I just tested it and dependencies are now being followed!