[CMake] Re: function and raise_scope commands

[Bill Hoffman]

Alexander Neundorf wrote:
> On Friday 18 January 2008, Alexander Neundorf wrote:
>> On Friday 18 January 2008, Rodolfo Schulz de Lima wrote:
>>> Miguel A. Figueroa-Villanueva wrote:
>>>> Again, I think this behaviour is a quite unintuitive and should be
>>>> well documented, at least.
>>> I shall add that at first I expected 'raise_scope' to work like 'set'
>>> when the parameter <value> is a list. But, for instance:
>>>
>>> set(mylist item1 item2 item3)
>>>
>>> set(var1 ${mylist})
>>> raise_scope(var2 ${mylist})
>>>
>>> in this example, var1 gets the 3 items, whereas var2 gets only 'item1'.
>>> That's odd and also counterintuitive.
>> How about the attached patch ?
>> It adds an argument PARENT_SCOPE to the SET() command, which then replaces
>> the RAISE_SCOPE() command:
>>
>> set(foo a b c PARENT_SCOPE)
>>
>> I'm not sure it is a good idea that this also propagates to the parent
>> directory. What is a use case for this ?
> 
> What do you think about this ?
> I think it's no good idea. Until now you can rely on that whatever happens in 
> subdirectories doesn't modify variables in the parent directory (the only way 
> is to force something through the cache, which is a bit ugly).
> If you need to get information from a subdir to some other place, with cmake 
> 2.6 you can use a global property to do this, which will also work over 
> multiple levels of subdirectories. Doing this using PARENT_SCOPE would 
> require to build a chain of these calls through all directories, which I 
> think is not very nice and can require relatively much code.
> 
> Do you have objections to removing that feature (propagating to the parent 
> directory) ?
> 
> 

I am pretty sure raise_scope was removed in favor of this version of 
set, so if you remove it, there will be no way to raise scope...