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...
_______________________________________________
CMake mailing list
[email protected]
http://www.cmake.org/mailman/listinfo/cmake
