Quantcast

COMMAND dependencies with add_custom_command()

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

COMMAND dependencies with add_custom_command()

Craig Scott-3
The documentation for add_custom_command() contains this little nugget when discussing the COMMAND keyword:

If COMMAND specifies an executable target name ...<snip>... Additionally a target-level dependency will be added so that the executable target will be built before any target using this custom command. However this does NOT add a file-level dependency that would cause the custom command to re-run whenever the executable is recompiled.

I'm struggling to come up with a scenario where that last part about file level dependencies becomes relevant. Can anyone come up with a simple use case which highlights that particular aspect of dependencies and commands?


--
Craig Scott
Melbourne, Australia

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: COMMAND dependencies with add_custom_command()

Matthew Woehlke-2
On 2017-01-25 20:25, Craig Scott wrote:

> The documentation for add_custom_command() contains this little nugget when
> discussing the COMMAND keyword:
>
> If COMMAND specifies an executable target name ...<snip>... Additionally a
>> target-level dependency will be added so that the executable target will be
>> built before any target using this custom command. However this does NOT
>> add a file-level dependency that would cause the custom command to re-run
>> whenever the executable is recompiled.
>
> I'm struggling to come up with a scenario where that last part about file
> level dependencies becomes relevant. Can anyone come up with a simple use
> case which highlights that particular aspect of dependencies and commands?

Let's start with an example, so we can talk about this concretely:

  add_executable(my_generator generate.cpp)
  add_custom_command(
    OUTPUT generated.out
    DEPENDS content.in
    COMMAND my_generator ...)

I think what this is saying is that the dependencies will be such that
if `generated.out` needs to be built, the build will ensure that
`my_generator` is built first (since the command would obviously fail
otherwise). However, the build will NOT be set up such that a change to
`generate.cpp` causes `generated.out` to be recreated. IOW, if
`generated.out` exists, it will only be considered "dirty" if it is
older than `content.in`, but NOT if it is older than `my_generator`.

Does that help?

--
Matthew
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: COMMAND dependencies with add_custom_command()

Craig Scott-3
Great, thanks. That was a similar case to the example I was using to experiment with this stuff, I just hadn't picked up that if generated.out already existed, it wouldn't be rebuilt if generate.cpp changed. Cheers.

On Thu, Feb 2, 2017 at 7:12 AM, Matthew Woehlke <[hidden email]> wrote:
On 2017-01-25 20:25, Craig Scott wrote:
> The documentation for add_custom_command() contains this little nugget when
> discussing the COMMAND keyword:
>
> If COMMAND specifies an executable target name ...<snip>... Additionally a
>> target-level dependency will be added so that the executable target will be
>> built before any target using this custom command. However this does NOT
>> add a file-level dependency that would cause the custom command to re-run
>> whenever the executable is recompiled.
>
> I'm struggling to come up with a scenario where that last part about file
> level dependencies becomes relevant. Can anyone come up with a simple use
> case which highlights that particular aspect of dependencies and commands?

Let's start with an example, so we can talk about this concretely:

  add_executable(my_generator generate.cpp)
  add_custom_command(
    OUTPUT generated.out
    DEPENDS content.in
    COMMAND my_generator ...)

I think what this is saying is that the dependencies will be such that
if `generated.out` needs to be built, the build will ensure that
`my_generator` is built first (since the command would obviously fail
otherwise). However, the build will NOT be set up such that a change to
`generate.cpp` causes `generated.out` to be recreated. IOW, if
`generated.out` exists, it will only be considered "dirty" if it is
older than `content.in`, but NOT if it is older than `my_generator`.

Does that help?

--
Matthew
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake



--
Craig Scott
Melbourne, Australia

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Loading...