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 _______________________________________________ CMake mailing list [email protected] http://www.cmake.org/mailman/listinfo/cmake
