I have a project where I hope to build a binary, named `final_exe`. The
build directory where `final_exe` ends up needs to contain a file called
`final_resource` in order for `final_exe` to be considered "built."
The file `final_resource` is generated by another binary, called
`generating_exe`, which I also build from source as part of my project.
Furthermore, for `generating_exe` to be considered "built" or "usable," a
file called `generating_resource` needs to be present in the directory
where `generating_exe` ends up. The file `generating_resource` is, say,
copied verbatim from the source tree.
There are many binaries in the project whose builds depend on
`generating_exe` (and, transitively, on `generating_resource`) in this
manner.
I can't think of a way to express this dependency graph cleanly in CMake.
First, the easiest thing to do is to add `POST_BUILD` custom commands to
the `final_exe` and `generating_exe` targets. I don't like this approach,
for a couple of reasons. If the copy of `generating_resource` located in
the source tree changes, without some extra work the `POST_BUILD` custom
commands won't get called. Developers would need to somehow convince the
build system to re-link `generating_exe`. (I am not even clear about how to
work around this from within my project's CMake scripts.) Then, even once
`generating_exe` is rebuilt, the developer _again_ has to convince the
build system to re-link `final_exe` (and any other executable, library,
etc., that depends on `final_resource`) in order to obtain a correctly
updated build.
(Suppose that `final_resource` is not a CPP file, etc., so it is not
natural to shove it into the list of sources of `final_exe`.)
(The above problem can be summed up by asking, how do you create a custom
command in the flavor of, e.g., a `POST_BUILD` command invoking
`${CMAKE_COMMAND} -E copy_if_different`, but which will be re-run if the
"source files" of the custom command are modified?)
A nice(r) solution to the above problems would be to create a custom
target, called `copy_generating_resource`, which invokes `${CMAKE_COMMAND}
-E copy_if_different`, and which would be run every build (because those
are the semantics of custom targets). This approach actually solves the
above issues in a reasonable way, except for the following problem:
A natural definition of `copy_generating_resource` involves the use of
`$<TARGET_FILE_DIR:generating_exe>` to specify the directory into which to
place `generating_resource`, which would make `copy_generating_resource` a
dependency of `generating_exe`. It is natural that `final_exe` depends on
`generating_exe`. However `generating_exe` is not actually usable until
`copy_generating_resource` is run. Furthermore, we cannot even awkwardly
declare `copy_generating_resource` to be a dependency of `generating_exe`,
because there is already a dependency between these two targets going in
the other direction.
It is very annoying to insist that the author of the `CMakeLists.txt` file
corresponding to `final_exe` must be aware that he needs to encode that
`final_exe` depends on `copy_generating_resource` manually. If he fails to
do so, he risks `generating_exe` being run (to generate `final_resource`)
before it is actually usable, in particular, before
`copy_generating_resource` is run.
Am I missing something?
Andrey Mishchenko
--
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
