Hi Brad:
The two generator expressions
$<$<COMPILE_LANG_AND_ID:D,GNU>:-pthread>
and
$<$<AND:$<COMPILE_LANGUAGE:D>,$<D_COMPILER_ID:GNU>>:-pthread>
are supposed to be equivalent according to the cmake-generator-expressions
manual.
Up to now I have always used the first form when setting the
INTERFACE_LINK_OPTIONS property of an interface library which my D
examples link with. All my tests of that form for both the test_d and
plplot cases work fine. So I was about to declare that my D language
support (a fork of the cmake-d project which I hope to merge back with
that project) was perfect for our needs (at least on Linux) until I
ran into a problem with the above second generator expression which I
will now describe.
Some old versions (e.g., 3.13.2) of CMake that PLplot still needs to
support do not implement the $<COMPILE_LANG_AND_ID:...> generator
expression so after the first form passed all tests, I tried switching
to the second generator expression for the plplot case. However, that
generated errors at CMake time which are typically (for each
of our D examples)
CMake Error at examples/d/CMakeLists.txt:119 (target_link_libraries):
Error evaluating generator expression:
$<D_COMPILER_ID:GNU>
Expression did not evaluate to a known generator expression
[...]
-- Generating done
CMake Generate step failed. Build files cannot be regenerated correctly.
These errors were obtained with cmake version 3.15.20190829-g3ec986c
(the version I have recently been using for testing).
This is a really peculiar result since both forms provide the same
information (language and compiler id) and are supposed to be
equivalent, i.e., both forms should either work or not work. And the
second form works for the Fortran case (where I am having to deal with
a similar -pthread issue). So my guess is there is some internal
implementation issue with the second form that makes it not quite
equivalent to the first form, and some minor issue with my D language
support (that otherwise works perfectly for PLplot needs on Linux) has exposed
this implementation difference.
If you confirm that guess, then ideally the CMake implementation
should be changed so the second form is equivalent to the first form
in all circumstances. And I would be happy to test that change with
my present CMake D language support.
I also need the second form of generator expression to work with older
unfixed CMake versions so once you spot the implementation difference
between the two forms I would also appreciate a hint about how to
change my CMake D language support so the present CMake code does not
generate the above type of errors for the second form of the generator
expression.
In case you need details about my present CMake D language support,
those can be found at either cmake/test_d/cmake/Modules or
cmake/modules/language_support/cmake-d_fork/ within the plplot source
tree. That source tree can be cloned using
git clone https://git.code.sf.net/p/plplot/plplot plplot.git
Alan
__________________________
Alan W. Irwin
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.org); 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:
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:
https://cmake.org/mailman/listinfo/cmake-developers
