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


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)
set_target_properties(depending_target PROPERTIES
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: 

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 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

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 

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 

Follow this link to subscribe/unsubscribe:

Reply via email to