10/12/2023 0 Comments Cmake generator expressionSee also the CMAKE_COMPILER_VERSION variable, which isĬlosely related to the expressions in this sub-section. $ġ if CMake's platform id matches any one of the entries inĬomma-separated list platform_ids, otherwise 0. Toolchain And Language Expressions ¶ Platform ¶ $ ¶ are evaluated using the custom command's "command config". With the Ninja Multi-Config generator, generator expressions Only valid in add_custom_command() and add_custom_target()Īs the outer-most generator expression in an argument. List() command, it is specific to the list-handling generator Since a comma is used to separate the list and the value, the listĬannot itself contain a comma. Must not contain any commas if that generator expression expects something toīe provided after the list. In each of the following list-related generator expressions, the list List() command, providing the same capabilities, but in Most of the expressions in this section are closely associated with the Same behavior as string(MAKE_C_IDENTIFIER). $ ¶Ĭontent of string converted to upper case. String Transformations ¶ $ ¶Ĭontent of string converted to lower case. For example, the followingĮvaluates to 1 if $ is any of BAR, Bar, bar, etc.ġ if v1 is a version greater than or equal to v2, else 0. For a case-insensitive comparison,Ĭombine with a string transforming generator expression. String Comparisons ¶ $ ¶ġ if string1 and string2 are equal, else 0. Other more specific comparison types are documented in their own separate ![]() This section covers the primary and most widely used comparison types. Primary Comparison Expressions ¶ĬMake supports a variety of generator expressions that compare things. The result of the expression isĠ if condition is 1, else 1. If allĬonditions evaluate to 0, the whole expression evaluates to 0. Where conditions is a comma-separated list of boolean expressions.Įvaluates to 1 if at least one of the conditions is 1. The whole expressionĮvaluates to 1 if all conditions are 1. Where conditions is a comma-separated list of boolean expressions,Īll of which must evaluate to either 1 or 0. The common boolean logic operators are supported: $ ¶ $: - DENABLE_SOME_FEATURE > Logical Operators ¶ Information specific to each build configuration. It would also be more consistent with the other functionality.Generator expressions are evaluated during build system generation to produce Would it be possible to change the behavior here with a new cmake policy? IE, check to see if the RHS of the BOOL:VARIABLE is an existing variable, and dereference it, like the other logical functions? I can’t imagine it would break existing code, as the only time people would be using it this way, would be if they were making a mistake, just as I was. Fortunately the fix was a good sed command across a bunch of files to add the $ characters, but in large projects, I’m sure it would go unnoticed. It was a mistake that was hard to find, and only after carefully reading the docs did I track it down. BUILD_ZLIB is interpreted as a literal string, which evaluates to TRUE. However, the generator expression expects a STRING variable here. In the ExternalProject_Add function, I have CMAKE_ARGS lines similar toĪ casual user might expect that the same boolean variable is dereferenced here as well, especially since there’s a giant “BOOL” setting right there beside it. If() would automatically dereference BUILD_ZLIB to see if it were true or false. ![]() In all of the logic handling functions, I would use this variable as if(BUILD_ZLIB) Using the ExternalPackage_Add function, I’m building a few third party dependencies, based on boolean variables that I set in earlier scripts, BUILD_ZLIB, and so on. ![]() ![]() I recently came across a bug in one of my projects build system, and I feel that its a result of an inconsistent design philosophy between the generator expressions, and the other logical functions.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |