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