Brad King wrote: > On 06/07/2012 01:25 PM, Stephen Kelly wrote: >> Although the questions are rhetorical, I'll answer them anyway to clarify >> the intention of the proposal. I'm not trying to push my proposal, but I >> want to make sure it's understood :). > > The reason I said they're rhetorical is I'm not interested in spending > further time on the design. The pure-$<> approach can be implemented > in a matter of hours or a couple days.
Great! > >> Assuming that a copy of relevant state can be created > > It can't. The internal implementation isn't clean enough for that. > We can't implement isolated environments in the language without > significant internal changes. This is a showstopper for most of > what you proposed. Ouch! >>> How do names/variables/functions in the generator_expression body bind? >> They don't. They are local to the generator_expression > > To what does BUILD_TESTING bind in your example? It wasn't passed in. > Is the generator expression a closure? (again, rhetorical) Good question. I have an answer, but I don't know if you want me to avoid posting it for fear of spending time discussing it. If in the future the showstopper is resolved (what I have in mind might even be the solution to it), then it might be useful to have in the thread. >> I'd even define these declarative expressions to only be valid on target >> properties, so that, eg, they can't be used in an include_directories() >> call. > > All generation takes place within the context of targets, so this does > not matter. Any value passed to the command in directory-level scope > will only be used later inside a target anyway. True. >> We'll still need to plan the implementation of it anyway :) > > cmGeneratorExpression::Evaluate can be taught to handle everything > pretty easily. > > Then more places need to be taught to pass values through instances > of cmGeneratorExpression, such as the INCLUDE_DIRECTORIES property > just before it is used in the generators. Each place that constructs > a cmGeneratorExpression instance must give it enough information to > evaluate all the expressions supported in that context. Documentation > must be updated accordingly, and tests added of course. So can this be done in 2.8.10? And can Kitware do it (I'm sure it would take me more than a few hours or days)? I can then see what impact the resolution of how this wikk work has on the rest of the plan in the wiki page. Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
