[CMake] What is the preferred method of establishing the dependence
of a custom command on an executable target?
Alan W. Irwin
irwin at beluga.phys.uvic.ca
Sat Apr 7 15:23:10 EDT 2007
The PLplot development team has the following build problem:
We use a executable built as a target to generate a header file which in
turn is used to do an (expensive) build of a library. Because of the
potential expense, we want the header file to be regenerated only when
absolutely necessary, i.e., only if a data file required to generate the
header is changed or the source code for the executable is changed.
Here is the critical part of the chain of dependencies that are set up
to deal correctly with the header generation.
**************************
add_executable(plhershey-unicode-gen ${plhershey-unicode-gen_SRCS})
add_custom_command(
OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/plhershey-unicode.h
COMMAND ${CMAKE_CURRENT_BINARY_DIR}/plhershey-unicode-gen${EXEEXT}
${CMAKE_SOURCE_DIR}/fonts/plhershey-unicode.csv
plhershey-unicode.h
DEPENDS
${CMAKE_CURRENT_BINARY_DIR}/plhershey-unicode-gen${EXEEXT}
${CMAKE_SOURCE_DIR}/fonts/plhershey-unicode.csv
)
**************************
(EXEEXT is '.exe' on windows and '' on Unix.)
Later on we have the library depend on a custom target that in turn file
depends on the custom command, and this chain of dependencies has worked
well (rebuilds only when plhershey-unicode.csv or
${plhershey-unicode-gen_SRCS} are touched) for Linux, Mac OS X, MinGW,
Cygwin, and several different bare-windows platforms.
However, one of our bare windows users did have problems with the chain of
dependencies. In particular, plhershey-unicode-gen.exe was apparently put
in the wrong build-tree directory so that the custom command could not find
it.
It's conceivable that the brute-force way we have used a file DEPENDS above
to make the custom target depend on the executable target could be the
source of this user's problems on his particular windows platform.
IMPORTANT: Is there some more preferred way to make a custom command depend
on an executable target or should the above logic always work
cross-platform?
To round this out in case you don't see any cross-platform problems in the
above logic, then here is this user's full report.
**************************
I tried it again with release building. Here is what I
did and what's going on.
1) I unpacked the plplot5.7.3 package into folder
D:\plplot-5.7.3
2) I launched the command-line window, ran the batch
file which set up the VC command env. And then typed
in:
cd plplot-5.7.3
mkdir vcxx
cd vcxx
cmake -G "Visual Studio 8 2005"
-DCMAKE_INSTALL_PREFIX=install ..
cmake proceeded to make the project files for VC++
2005, and no error message.
3) I launched VC++ 2005, and opened the project file
created by cmake in folder D:\plplot-5.7.3\vcxx.
4) Build the library with release configuration, and I
got the same fail:
Generating plhershey-unicode.h
'plhershey-unicode-gen.exe' is not recognized as an
internal or external command,
operable program or batch file.
I searched the file 'plhershey-unicode-gen.exe'. It is
located at "D:\plplot-5.7.3\VCXX\include\release" on
my computer. I used it to generate
'plhershey-unicode-gen.h' on command-line, and again
it worked. It seems that the compiler could not find
the file 'plhershey-unicode-gen.exe' with the settings
in CMakeList.txt.
5) Other than this fail, the compilation of other
library files seems okay although with some warnings.
**************************
If you spot anything in his report that seems off, please let me know, and I
will pass it on for interpretation to the members of the PLplot development
team who are windows capable (unlike me).
Alan
__________________________
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the
Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________
Linux-powered Science
__________________________
More information about the CMake
mailing list