-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi,
some time ago there was a discussion, which has highlighted problem I am facing now, but it did not provide final conclusions (http://www.cmake.org/pipermail/cmake/2008-September/024093.html). Take this example: - -------------------------- INCLUDE_DIRECTORIES( ${CMAKE_CURRENT_SOURCE_DIR} ) SET_SOURCE_FILE_PROPERTIES( ${CMAKE_CURRENT_SOURCE_DIR}/a.h PROPERTIES GENERATED TRUE ) ADD_CUSTOM_COMMAND( OUTPUT "${CMAKE_CURRENT_SOURCE_DIR}/a.h" COMMAND echo \"\#define STAMP \\\"\" `date` \"\\\"\" > a.h DEPENDS "${CMAKE_CURRENT_SOURCE_DIR}/a.txt" ) ADD_CUSTOM_TARGET( a_h_gen DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/a.h ) ADD_LIBRARY( foo STATIC a.c ) - --------------------------------- Here we have file a.c which includes file a.h. a.h is generated, with dependency on a.txt. What I'd expect from the above (and what ZNV hinted in the 2008 thread) building foo library should check dependencies of a.c and if a.h doesn't exist generate it or it a.txt has changed regenerate a.h However, files generated with cmake 2.6.4 show that: 1. in Makefile2 a.c has no dependencies on a.h or a_h_gen 2. depend.make for foo library has dependency on a.h only if a.h existed at the time of cmake execution or during dependency scanning for a.c The result is that building foo doesn't generate a.h nor a.h is refreshed if a.txt changed even though depend.make for foo lists a.h as its dependency. If I add the following line at the end: ADD_DEPENDENCIES( foo a_h_gen ) a dependency for foo on a_h_gen will appear in Makefile2 and everything will work as expected. This however, in a real life example I am working on there are hundreds of source files and tens of libraries which indirectly may depend on a generated header and thus manual specification of dependency between built library and generated file is simply impractical. Thus, my question is whether I am missing something in my example CMakeLists.txt or cmake at this stage is simply unable to handle such situation. In the 2008 discussion ZNV illustrated exactly the same situation by the single vs. two-level dependency illustration, and Esben's response was that properly constructed CMakeLists.txt file shall enforce single level of dependencies. Nonetheless, the example above shows that it is not the case. Any hints allowing me to reach the desired cmake behaviour will be appreciated. THANKS. - -Wojciech -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKprET0iFl+nAyImcRAritAJ94VawRLcOh55U6uBu+QECWbVKB7wCffST5 TYAJVZC8mGhNp3yO9fVue2Y= =LYc3 -----END PGP SIGNATURE----- ---------------------------------------------------------------------- Wykonaj diagnostyke skory i odbierz swoj Prezent! http://link.interia.pl/f22f1 _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
