[cmake-developers] [PATCH v5 0/4] Add continue keyword

[Gregor Jasny]

On 18/11/14 17:19, Ben Boeckel wrote:
> On Tue, Nov 18, 2014 at 16:34:28 +0100, Gregor Jasny wrote:
>> Changes compared to v4:
>> * Use new style error reporting in cmContinueCommand.cxx
>> * Reject any given arguments to continue()
>> * CMP0055: Reject any arguments to break, too.

> I wonder if we should
> fix anything about it and if so, make continue behave in an analogous
> way

You want to make continue() bug compatible to break()?

> before it might also need a policy[1]:
> 
> -------- loop.cmake ---------
> function (my_breakf)
>     break()
> endfunction ()
> 
> macro (my_breakm)
>     break()
> endmacro ()
> 
> foreach (a IN ITEMS 1 2 3)
>     my_breakf()
>     message("-->${a}<--")
> endforeach ()
> 
> foreach (a IN ITEMS 4 5 6)
>     my_breakm()
>     message("-->${a}<--")
> endforeach ()
> -------- loop.cmake ---------
> 
> Which prints:
> 
> -->1<--
> -->2<--
> -->3<--

So the break in the macro worked, the break in the function got ignored.
This is expected behavior. The macro currently does not form an own
scope. Also variables set inside escape into the calling scope.

The function forms an own scope (due to the Push/PopScope call).

I think it is sane behavior that a macro does not form a scope / loop
context behavior. Or do you read macro like "macro function"?

> without any error messages (e.g., about using break() outside a

This is because CMP0055 defaults to OLD here. If you add
"cmake_policy(SET CMP0055 NEW)" here you'll get a nice error.

> loop…which doesn't seem to happen anyways, so maybe this is moot). I
> don't see any existing tests about break inside of a function or macro
> having an effect on the caller's logic.

What do you mean with 'effect' here?