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