[CMake] Generated source files and dependencies(+) (Esben Mose Hansen)

[Esben Mose Hansen]

On Tuesday 16 September 2008 21:48:16 ZNV wrote:

> > That is what dependency tracking is for. And that should be handled
> > automatically by the add_custom_target.
>
> My experience contradicts your statement.

Yeah, my bad. add_custom_command adds dependencies, not add_custom_target. In 
fact, the man page tells us that such target generates *no* output. Thus, 
nothing can depend on it, and it will always be build if appropriate.

> For instance if I remove 'ALL' token from my ADD_CUSTOM_TARGET,
> 'generate' target is not built at all. If I move 'generate' target
> declaration
> below 'foo' and 'bar', CMake attempts to build targets in wrong order:
> (1)foo, (2)bar, (3)generate.

You should generate your header with the ADD_CUSTOM_COMMAND. I can't see why 
the ADD_CUSTOM_TARGET should be necessary at all. The generated header should 
automatically become a dependency for the libraries.

>
> I mean, within a target file-to-file dependencies are tracked. If any file
> is updated, everything depending on that file within the target is rebuilt.
> Compiler, linker or random utility hooked in by ADD_CUSTOM_COMMAND
> runs.
>
> Additionally there are target-to-target dependencies. Some targets get
> the timestamp from associated output file (like ADD_LIBRARY or
> ADD_EXECUTABLE does). Other ones (like ADD_CUSTOM_TARGET)
> are always considered out of date. Inter-target dependencies are
> created either explicitly with ADD_DEPENDENCIES or implicitly
> as side effect of another command like TARGET_LINK_LIBRARIES.

That is pretty close to what the man page say, so broadly yes. 

> It looks like file-to-file dependencies do not span target boundaries.
> Consider the following dependency graph:
>
> random_data -> generated.h -> foo.c
>
> It appears to me that this graph actually breaks into two parts
> without contributing to targets relative ordering:
>
> generated [random_data -> generated.h]
> foo           [generated.h -> foo.c]
>
> Please correct my guesswork if I was wrong.

A correctly written cmake file would generate the first dependency graph. 
Again, I refer you to my google protocols buffers example, which does just 
this.

>
> If formal model behind CMake was written down, and availible
> online alongside with already perfect per-command help it will
> be so nice!

Can't help you there.
-- 
kind regards, Esben