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

2019-10-24 Thread 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?

2019-10-24 Thread 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