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

[Alan W. Irwin]

On 2018-02-19 13:03-0700 Sam Edwards wrote:

> Alan,
>
> I'm kicking myself for leaving off the DEPENDS in add_custom_target as that
> is the most essential part of what you suggested. Bah!
>
> I tried copying in your changes verbatim and I'm still left with an output
> that produces IS_INTERROGATE=0. This is on both 3.9.6 (my development
> machine) and 2.8.12 (my testing VM). Does your version of CMake produce
> IS_INTERROGATE=1 with your changes?

I don't want to get involved in too much further testing since the
overview of what you are attempting to do with generator expressions
is beyond my expertise.  However, I did build the following simple
project (with CMake-3.6.2)

cmake_minimum_required(VERSION 3.6.2 FATAL_ERROR)
project(test NONE)
add_custom_target(depending_target)
set_target_properties(depending_target PROPERTIES
   IS_INTERROGATE 1)
get_target_property(target_interrogate depending_target IS_INTERROGATE)
message(STATUS "target_interrogate = ${target_interrogate}")

The results were

-- target_interrogate = 1
-- Configuring done
-- Generating done
-- Build files have been written to: /home/software/plplot/HEAD/build_dir/test_build

That result confirms that if you set that property on a custom target,
then that value is accessible via get_target_property (as expected).
So I don't know why that value is not currently accessible to you with
generator expressions, but for what it is worth (since this is beyond
my CMake expertise) I think it should be.  Anyhow, to debug this
further I suggest you simplify your test case even further (similar to
above) and compare generator expression results with
get_target_property results to try and understand what is going
on with the generator expression version.

>
> The rationale behind 2.8.12 is this is the version that ships with Ubuntu
> Trusty and will probably be what's present if a user is simply told to
> "install CMake" - although 3.5.1 is also available on that platform under
> the cmake3 package, so I might be able to justify a minimum version of
> either that or 3.0.1 (which is what's on backports-less Debian Jessie). I'd
> have to bring it up with the project maintainer to see, but in any case
> we're trying to follow a "stick with the same minimum version until we
> encounter a bug we can't work around, then bump the minimum to the version
> that fixes that bug" approach.

I would take the opposite approach, i.e., develop for the latest CMake, and
then once that completely works, push the minimum version to smaller
values to see how far you can get before you run into any difficulties.

In any case, I would definitely avoid early CMake 3 versions such as
3.0.1 for the reasons I mentioned.  I hauled that around on my back
for a while by working around its bugs with the PLplot build system,
but it was quite a lot of effort, and that build system became
somewhat simpler once I bumped the minimum cmake version to 3.6.2.

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
__________________________