Hi Michael, Yes you are totally right. And indeed I am using a second "touch" command like you to solve my problem.
Thanks a lot, Arnaud. PS: sorry for the reply address in the past, wrong manipulation. On Fri, Aug 21, 2009 at 11:03 AM, Michael Wild <[email protected]> wrote: > Hi Arnaud > > Thing is, CMake doesn't do any of the deciding whether something is out of > date or not. This is delegated to the native build system. Let's look at > Make. Here, CMake generates a normal rule, looking something like this > (where I left the CMake-variables unsubstituted): > > ${${PROJECT_NAME}_WOK_GENERATED_INCLUDE}: ${${PROJECT_NAME}_CDLS} > woktcl ${CMAKE_CURRENT_BINARY_DIR}/${PROJECT_NAME}.tcl > > > This tells Make how to produce the outputs > ${${PROJECT_NAME}_WOK_GENERATED_INCLUDE} which depend on > ${${PROJECT_NAME}_CDLS} using woktcl. And all Make versions I know of simply > compare modification time stamps. Nothing CMake can do anything about, > really. > > So, what happens in your case probably is the following (and tell me if I'm > wrong). Your TCL script looks at the CDL files and then decides whether it > should update the output or not, right? If it doesn't, the time-stamp of > some of the outputs won't be updated, resulting in Make thinking the target > is out of date. And since probably more than one target depends on the > output of your custom-command (if you're generating headers, every source > file including any of the generated headers will depend on the custom > command), the custom command will be run for every target depending on its > output, resulting in your multiple executions. Now, the way to solve this is > really simple: > > ADD_CUSTOM_COMMAND( > OUTPUT ${${PROJECT_NAME}_WOK_GENERATED_INCLUDE} > COMMAND woktcl ARGS ${CMAKE_CURRENT_BINARY_DIR}/${PROJECT_NAME}.tcl > COMMAND ${CMAKE_COMMAND} ARGS -E touch > ${${PROJECT_NAME}_WOK_GENERATED_INCLUDE > DEPENDS ${${PROJECT_NAME}_CDLS} > COMMENT "Generating ${PROJECT_NAME} include files from CDLs" > ) > > The line I added just ensures that the modification time of all output > files will be updated, no matter whether your script made any changes or > not. > > I hope this helps > > Michael > > PS: I notice you replied to Tyler directly. Please keep your messages on > the list, such that others can profit from the discussion (and can follow > it). For most mail-clients this works best by just hitting "reply-to-all". > The mailing list (with the default settings) is then smart enough to not > send a duplicate to people figuring in the To: and Cc: fields. > > > On 21. Aug, 2009, at 10:24, Arnaud Devalkeneer wrote: > > Hello Tyler, >> >> I am not fully agree with your opinion. >> >> In my case, I can't change the command behaviour I call. So I must tune >> cmake scripts to make it works. >> In other words, the sentence : >> " If the DEPENDS are newer than the >> OUTPUT, then the OUTPUT *must* be out of date and should be regenerated." >> is a too strong assumption in my case. >> >> More comparison between last make execution time AND last modified >> dependency times must be enough to make cmake awares of >> custom command triggering in a general case (like for source files I >> guess). >> Mustn't it? >> >> Anyway there is a workaround using temporary files, but it is not so >> beautifull... >> >> Thanks a lot for your support. >> >> Arnaud. >> >> On Wed, Aug 19, 2009 at 5:13 PM, Tyler Roscoe <[email protected]> wrote: >> >> Putting this back on the list. >>> >>> On Wed, Aug 19, 2009 at 01:55:14PM +0200, Arnaud Devalkeneer wrote: >>> >>>> I just understood the cmake behaviour. >>>> In fact cmake seems to compare last modified times for output and >>>> dependencies. >>>> If the dependencies are younger than the output, the command is >>>> >>> triggered. >>> >>>> Right? >>>> >>>> But if the custom command has its own state machine to decide if the >>>> >>> output >>> >>>> should be re-generated according to dependencies change, >>>> this mechanism does not work if the output is not regenerated. In this >>>> >>> case, >>> >>>> the output always remains older than dependencies, and the command is >>>> >>> always >>> >>>> called. >>>> >>>> In my mind I thought that cmake behaviour is ONLY based on last make >>>> executing time and last modified dependencies times. But it seems not !! >>>> It seems that a comparaison between last modified times of output and >>>> dependencies occurs which is I think an error in a general purpose. >>>> Cmake should not make assumption about user command, and potential >>>> update >>>> >>> of >>> >>>> the output. Are you agree with that? >>>> >>> >>> Maybe I'm not understanding you, but are you saying that you don't want >>> CMake to check whether the OUTPUT is out of date, just the DEPENDS are >>> out of date? That doesn't make sense. If the DEPENDS are newer than the >>> OUTPUT, then the OUTPUT *must* be out of date and should be regenerated. >>> >>> tyler >>> >>> _______________________________________________ >> 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 >> > >
_______________________________________________ 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
