![]() ![]() ![]() If the entire expression is too difficult to unpack at first, just consider these two cases: The above example also shows the mentioned nesting – the conditional part of the expression is in this case a generator-expression itself – $ – this is a variable-querry conditional expression – it compares the actual configuration the target is being built with (what CONFIG evaluates to) to the value specified after the colon ( Debug). Here the target Foo is linked with additional instrumentation providing code-coverage, but only if the build configuration is equal to Debug. The most common example is specifying compiler or linker flags: add_library(Foo. As a rule of thumb everytime you’re about to use an if-else statement consider if a conditional generator-expression wouldn’t be a more succinct and readable alternative. The other is that generator-expressions can be nested arbitrarily, meaning that both condition and value-if-true can themselves be generator-expressions. This is probably one of the most important properties of generator expression syntax to understand. The result of the entire conditional expression is value-if-true if the condition evaluates to 1, and an empty string otherwise. Where the condition is an arbitrary expression evaluated to 0 or 1. This is due to the fact that generator-expressions can replace if-else statements in properties context.Ī conditional expression boils down to the following form: $ Most generator-expressions in the wild will contain a conditional component. Let’s have a brief look at each of these. Most notably it can be one of the following: The part between the angle brackets can vary quite widely. In its most general form a generator expression is specified with a dollar-sign and a pair of angle brackets: $ Now that you know where generator expressions can be used, let’s see how to use them. You’ll develop a feel for it with time, just consult the documentation for specifics as you go. There are exceptions to this of course – if a variable is later used by cmake to initialize properties on targets, then you’ll get the desired effect. ![]() On the other hand if you try using generator-expressions on plain variables you’re bound to have a bad time. Expect generator-expressions to be usable with all of the commands prefixed with target_ ( target_include_directories etc.) and commands that operate on properties directly ( set_target_properties, etc.). Well, broadly speaking generator-expressions, much like most of modern CMake, work with targets and properties – if a command deals with a target and modifies its properties in some way, chances are you’ll be able to use generator-expressions with that command. That’s great, but what does this actually mean in practical terms? With which specific commands can I, or can I not use generator-expressions? build – generator-expressions are OK here.generation – generator-expressions are OK here.configuration – can’t use generator-expressions here.So the actual cmake build process stages are: As a result, they can not be used before that – i.e. ![]() As the name might suggest generator-expressions are evaluated during the generation stage. This is the stage where cmake actually generates the specified (or default for the platform, if omitted) build system. However, if on closer inspection of cmake’s output during the configuration stage it is apparent that another distinct stage is present – the generation stage: $ cmake -B build -S. These two stages are obvious, as they are two separate actions that the user must take.
0 Comments
Leave a Reply. |