[CCPPETMR/SIRF] Run gmi_x* after relevant file has been updated (#372)

瀏覽次數:0 次
跳到第一則未讀訊息

Richard Brown

未讀,
2019年4月26日 中午12:05:362019/4/26
收件者:CCPPETMR/SIRF、Subscribed

If we alter cstir.h, we need to run gmi_xstir (and similar for other packages).

It would be good if CMake detected changes to the relevant files (cstir.h, cgadgetron.h, creg.h, etc.) and run the relevant executably (gmi_xstir, gmi_xgadgetron, gmi_xreg, etc.).

I'm alsmot 100% sure this is possible in CMake, I just can't remember how to do it.


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

Edoardo Pasca

未讀,
2019年4月29日 凌晨4:40:172019/4/29
收件者:CCPPETMR/SIRF、Subscribed

You'll have to create a custom target depending on gmi_xstir and cstir.h which will run the specific command you need.

Richard Brown

未讀,
2019年4月29日 清晨5:26:052019/4/29
收件者:CCPPETMR/SIRF、Subscribed
# Re-run gmi_xreg if cReg.h has changed
ADD_CUSTOM_COMMAND(
    OUTPUT ""
    COMMAND "gmi_xreg" 
    DEPENDS "../../cReg/cReg.h"
)

I tried this, but it's not correct. Any ideas?

Edoardo Pasca

未讀,
2019年4月29日 清晨6:18:442019/4/29
收件者:CCPPETMR/SIRF、Subscribed

What do you mean "is not correct"?
I normally set the OUTPUT but it may be that the relative path to cReg.h is not resolved properly.

ADD_CUSTOM_COMMAND(
    OUTPUT "${CMAKE_CURRENT_BINARY_DIR}/build/timestamp"
    COMMAND "gmi_xreg" 
    DEPENDS "${CMAKE_CURRENT_SOURCE_DIR}/../../cReg/cReg.h"
)

Richard Brown

未讀,
2019年4月29日 清晨6:52:122019/4/29
收件者:CCPPETMR/SIRF、Subscribed

Using your example everything compiles, but when I change cReg.h, mReg.c isn't updated accordingly. (which is what I meant by "not correct").

Edoardo Pasca

未讀,
2019年4月29日 清晨7:21:112019/4/29
收件者:CCPPETMR/SIRF、Subscribed

Is the command gmi_xreg issued at any time if you update cReg.h? Or the change of cReg.h is not picked by CMake?

Richard Brown

未讀,
2019年4月29日 上午8:48:222019/4/29
收件者:CCPPETMR/SIRF、Subscribed

I'm not sure whether the change of cReg.h isn't being detected (seems unlikely), or if I'm not using the command properly (more likely). At any rate, gmi_xreg isn't being run during the make stage.

Edoardo Pasca

未讀,
2019年4月29日 上午9:46:072019/4/29
收件者:CCPPETMR/SIRF、Subscribed

I tried on a simplified example. Adding a target works

add_custom_target(
    run_gmi 
    COMMAND gmi_xreg 
    DEPENDS "${CMAKE_CURRENT_SOURCE_DIR}/head.h"
)

but you'll run it with make run_gmi

Edoardo Pasca

未讀,
2019年4月29日 上午10:44:172019/4/29
收件者:CCPPETMR/SIRF、Subscribed

There are 2 signatures of the add_custom_command.

You are trying to use the first and the documentation is less than clear here. In practice the add_custom_command is not run at all unless you attach it to a target. Therefore one has to add a target. In the following I have created a hello target which is a hello-world program.

The custom target depends on the OUTPUT of the custom command and it will output a file named timestamp in the ${CMAKE_CURRENT_BINARY_DIR} with the content of the output of command hello

I hope this clarifies.

set(OUTPUT timestamp)
add_custom_command(
    OUTPUT ${OUTPUT}
    COMMAND hello  > ${OUTPUT}
    DEPENDS hello 
    WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
)
add_custom_target(custom DEPENDS ${OUTPUT})

Additionally be careful as

Do not list the output in more than one independent target that may build in parallel or the two instances of the rule may conflict (instead use the add_custom_target() command to drive the command and make the other targets depend on that one).

The second signature

adds a custom command to a target such as a library or executable. This defines a new command that will be associated with building the specified <target>.

Richard Brown

未讀,
2019年4月30日 清晨6:53:332019/4/30
收件者:CCPPETMR/SIRF、Subscribed

Sorry, I can't follow your example. What's head.h and what's the custom target custom?

From my side, this is as I've got: rijobro@3ab7954

It's not great because:

  1. the command gmi_xreg is run every time cmake is run.
  2. I had to create a dummy executable test1.

If this is easy for you (because I'm struggling!), feel free to commit directly to my branch.

Edoardo Pasca

未讀,
2019年5月1日 清晨5:46:452019/5/1
收件者:CCPPETMR/SIRF、Subscribed

I think you did right. The custom command is only run if you specifically attach to a target, which is what you did by create_custom_target. Now, this target must depend on the source you want to monitor.

The additional problem would be that you need to make your new target become a dependency of install, probably.

Kris Thielemans

未讀,
2019年5月1日 清晨6:24:512019/5/1
收件者:CCPPETMR/SIRF、Subscribed

there's some target/dependency stuff in UCL/STIR#280 (where I resolved it for doxygen)

Kris Thielemans

未讀,
2019年6月14日 下午5:58:532019/6/14
收件者:CCPPETMR/SIRF、Subscribed

Some doc on this is at https://crascit.com/2017/04/18/generated-sources-in-cmake-builds/

As gmi_xreg creates both mreg.h, mreg.c, it seems to me that you need to say

add_executable(gmi_xreg gmi_xreg.cpp)

# Re-run gmi_xreg if cReg.h has changed
ADD_CUSTOM_COMMAND
(
    OUTPUT mreg.h mreg.c
    COMMAND "gmi_xreg" 
    DEPENDS "../../cReg/cReg.h" "gmi_xreg"
)

add_executable(mreg ${CMAKE_CURRENT_BINARY_DIR}/mreg.c ${CMAKE_CURRENT_BINARY_DIR}/mreg.h)

INSTALL(TARGETS mreg DESTINATION ${MATLAB_DEST})

A problem then is that gmi_xreg relies on the SIRF_PATH env variable
https://github.com/CCPPETMR/SIRF/blob/51d131ef1b945560e131f5585df108ba744f6c2f/src/Registration/mReg/gmi/gmi_xreg.cpp#L56
I'm not 100% sure why this is as I haven't checked the output. Presumably, this path could/should be passed as an argument to gmi_xreg. @evgueni-ovtchinnikov could help with that.

回覆所有人
回覆作者
轉寄
0 則新訊息