Re: [cmake-developers] These two generator expressions should be equivalent, but one working while the other not working. Bug?

[Alan W. Irwin]

On 2019-10-24 12:41-0700 Alan W. Irwin wrote:

[ W]ould you entertain a feature request to remove 
that

hard-coded language limitation on the above 4 classes of genex so both
internally and externally supported languages would work for all of
them?


Well, since you did not respond I assume you are at least not horrified by that 
idea
so I have written this up as 

and further discussion should appear there.

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

Re: [cmake-developers] These two generator expressions should be equivalent, but one working while the other not working. Bug?

[Alan W. Irwin]

On 2019-10-24 08:08-0400 Brad King wrote:


On 10/24/19 12:18 AM, Alan W. Irwin wrote:

 $

   Expression did not evaluate to a known generator expression


The `*_COMPILER_ID` generator expressions are a hard-coded set
corresponding to the languages supported by upstream CMake:

* C_COMPILER_ID
* CXX_COMPILER_ID
* CUDA_COMPILER_ID
* Fortran_COMPILER_ID
* OBJC_COMPILER_ID   (new in 3.16)
* OBJCXX_COMPILER_ID (new in 3.16)

This is because the language name is part of the expression name.

In the `$` case, the language name
is one of the parameters.


Thanks for that clear explanation of this current CMake hard-coded limitation.

To work around it, I will stick with the $
genex, but only bother with that -pthread mapping for cmake 3.15.0 and above
(since that is the first version of CMake to support 
$).

So that takes care of PLplot's needs.  However, on the general question of the
above CMake hard-coded language limitation I searched through

for "CXX" and found these genex's

$<"language"_COMPILER_ID:compiler_ids>
$<"language"_COMPILER_VERSION:version>
$<"language"_COMPILER_ID>
$<"language"_COMPILER_VERSION>

where I have substituted "language" for CXX to indicate these actually 
represent 4 different
classes of genex's where "language" is currently on a hard-coded list for the 
first, and
it appears from Source/cmGeneratorExpressionNode.cxx
that is true of the rest as well.

My C++ skills are limited and as a result I don't understand the CMake
code that well, and I don't have any idea how difficult this would be to
implement.  So I should ask would you entertain a feature request to remove that
hard-coded language limitation on the above 4 classes of genex so both
internally and externally supported languages would work for all of
them?

For example, you currently have

$<"language"_COMPILER_ID:compiler_ids> where compiler_ids is a comma-separated
list. 1 if the CMake’s compiler id of the "language" compiler matches any
one of the entries in compiler_ids, otherwise 0. See also the
CMAKE__COMPILER_ID variable

where "language" is restricted to the above hard-coded list.
Would it be straightforward to change the implementation of this
whole class of genexes so that "language" was simply determined from
the first part of the genex name with that "language" then checked
against the available language support?

If so, that approach would solve the above issue (i.e., drop this
artificial distinction between languages with internal and external
support) and also have the additional advantages that it would replace
what I presume are currently 6 different genex implementations and the
documentation of each of those with just one implementation and
corresponding piece of documentation with no introduced backwards
incompatibilities due to this change.

And similarly for

$<"language"_COMPILER_VERSION:version>
$<"language"_COMPILER_ID>
$<"language"_COMPILER_VERSION>

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

Re: [cmake-developers] These two generator expressions should be equivalent, but one working while the other not working. Bug?

[Brad King via cmake-developers]

On 10/24/19 12:18 AM, Alan W. Irwin wrote:
>  $
> 
>Expression did not evaluate to a known generator expression

The `*_COMPILER_ID` generator expressions are a hard-coded set
corresponding to the languages supported by upstream CMake:

* C_COMPILER_ID
* CXX_COMPILER_ID
* CUDA_COMPILER_ID
* Fortran_COMPILER_ID
* OBJC_COMPILER_ID   (new in 3.16)
* OBJCXX_COMPILER_ID (new in 3.16)

This is because the language name is part of the expression name.

In the `$` case, the language name
is one of the parameters.

-Brad
-- 

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

[cmake-developers] These two generator expressions should be equivalent, but one working while the other not working. Bug?

[Alan W. Irwin]

Hi Brad:

The two generator expressions

$<$:-pthread>

and

$<$,$>:-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 $ 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:

$

  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