[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:
>>      $<D_COMPILER_ID:GNU>
>>
>>    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 `$<COMPILE_LANG_AND_ID:D,GNU>` 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 $<COMPILE_LANG_AND_ID:D,GNU>
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 $<COMPILE_LANG_AND_ID:...>).

So that takes care of PLplot's needs.  However, on the general question of the
above CMake hard-coded language limitation I searched through
<https://cmake.org/cmake/help/latest/manual/cmake-generator-expressions.7.html>
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_<LANG>_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
__________________________