Thanks, yes now I recall seeing that back then but didn’t get to follow up at the time. I’m not sure I necessarily agree with the reasoning stated there. @brad.king’s comment:
cmake_language(CALL <command> [<args>...]) evaluates
<args> after the command name at the point at which the call is made. No additional layer of evaluation is added. It just happens that the call is made immediately in that case.
I recall having previous discussions about that, see issue 20707 for the details. To the user, this appears as an internal implementation detail, since it still looks to them as though variables are evaluated as normal. Maybe there’s a corner case where it makes a difference, but I note that there is no mention in the docs about this delayed evaluation.
Continuing with Brad’s reasoning:
DEFER case, the
CALL has the same argument evaluation semantics, but the time the call is made happens to be later. Delaying argument evaluation:
- is consistent with the existing
- is consistent with the documentation stating that the call is made as if written at the end of the
- provides a lot of power from which one can opt-out with EVAL anyway, and
- happens to be
easier possible to implement.
I’m suggesting that while the DEFER case might be consistent with the implementation of the CALL signature, it doesn’t seem consistent with the perceived behavior. Also, rather than having to opt-out using EVAL, one could effectively opt-in by using bracket syntax to avoid evaluation at the call site.
Reading back over the discussions again in issue 20707, I can’t say how feasible it is to evaluate variables immediately at the call to
cmake_command(). I’ve raised my concerns about consistency and intuitive behavior, but I’ll have to defer to @brad.king on this.