[CMake] Generator expressions: Identifying when they're used in a custom command?

[Alan W. Irwin]

On 2018-02-18 19:47-0700 Sam Edwards wrote:

> Alan,
>
> Thanks for your help! I tried to implement that paradigm myself in a small
> example CMakeLists.txt which I've attached, but the addition of a depending
> custom target doesn't seem to change the context of the 'this' target. In
> other words, the IS_INTERROGATE property is still read from fake_target and
> not depending_target.
>
> Could you take a look and clarify what I'm not doing quite right?

Hi Sam:

I just looked at the custom command part of it which was

add_custom_command(OUTPUT source.c
   COMMAND "${PYTHON_EXECUTABLE}" "${script_path}"
"$<TARGET_PROPERTY:fake_target,INTERFACE_INCLUDE_DIRECTORIES>" >
source.c)

# Add a custom target to depend on source.c, as suggested
add_custom_target(depending_target)
set_target_properties(depending_target PROPERTIES
   IS_INTERROGATE 1)

# Compile the output
add_executable(output source.c)
# Make sure we depend on the custom target
add_dependencies(output depending_target)

I would change the above to the following:

add_custom_command(OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/source.c
   COMMAND "${PYTHON_EXECUTABLE}" "${script_path}"
"$<TARGET_PROPERTY:fake_target,INTERFACE_INCLUDE_DIRECTORIES>" >
source.c)

# Add a custom target to depend on source.c, as suggested
add_custom_target(depending_target
DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/source.c)
set_target_properties(depending_target PROPERTIES
   IS_INTERROGATE 1)

# Compile the output
add_executable(output ${CMAKE_CURRENT_BINARY_DIR}/source.c)

Here are my reasons for the suggested changes.

* Absolute path when referring to source.c.  I am not sure whether
   this is stylistic or required, but this style works for me.

* Use DEPENDS to make the custom target depend on the custom command.
   This change is essential.

* Drop add_dependency.  The typical way you let CMake know that source
code is generated is with the GENERATED property which should take
care of all dependencies.  However,
<https://cmake.org/cmake/help/v3.11/prop_sf/GENERATED.html> implies to
me you do not even need to specify the GENERATED property for
${CMAKE_CURRENT_BINARY_DIR}/source.c.  So try the above and see, and
if it does not work try using the GENERATED property.

* Set a much higher minimum CMake version.  You mentioned CMake
2.8.12+ in your original post, but there are some fundamental
differences between CMake-2 and CMake-3, and in my opinion you are
just making a rod for your back if you try to make your build system
work for both.  For example, I have no idea whether the above approach
will work for 2.8.12.  Another constraint is early versions of CMake-3 were
frankly buggy.  So I use a minimum version of CMake-3.6.2 for all my
build systems, and that works well for me.  Note all modern
Linux distributions, Cygwin, MinGW-w64/MSYS2, HomeBrew, MacPorts, and
Fink all provide that version of CMake or higher, and Kitware provides
CMake for that version and higher for MSVC as well so that choice of minimum
CMake version should inconvenience very few of your potential users.

I hope these suggested changes help you toward your broader goal.

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); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________