Brad King wrote:
> On 05/13/2012 05:50 PM, Stephen Kelly wrote:
>> The remaining (I think) open question regards what form the generator
>> expressions should take so that they can represent multiple dimensions.
>
> Multiple dimensions will inevitably need to be combined in arbitrary
> boolean expressions.
I guess you're right. I thought we could maybe get by with just AND and NOT,
but it kind of depends on whether these expressions should be human-
readable, human-writable, or runtime-editable.
I mean, to represent
if (Config == Debug && (Language == "CXX" || Scope == "Public")
we could use
$<Config=Debug&Language=CXX:/foo/bar>
$<Config=Debug&Scope=Public:/foo/bar>
But that would be awkward in cases where you want to do runtime-editing:
* Get the current value of the property
* Check something in it.
** Conditionally add to or remove from it
* Set it back on the target.
I think any solution we come up with will have this problem though, so we
may want to address whether that should be possible at all, or if the design
needs to explicitly have uses like that in mind.
> I'm concerned that this will lead to a whole new
> piece to the language that will be hard to get right without knowledge
> of future use cases. We will need to ensure that parsing of generator
> expressions is *very* strict so we can extend the syntax easily later.
Yes.
> Perhaps the simplest thing to do is implement something like the normal
> CMake IF() command in generator expressions. Factor the IF() expression
> evaluation out for re-use. Teach the generator expression parser to
> extract the IF() part (with nested $<> expressions already evaluated,
> something the generator expression evaluator already knows how to do)
> and pass it through the IF() evaluator. For example:
>
> "$<IF($<CONFIGURATION> MATCHES Debug AND $<LANGUAGE> STREQUALS CXX)...>"
>
> I'm not sure what should go in the "..." part though. Some syntax to
> delimit the then/else values would be needed.
I'm not sure else() and endif() are needed as additional expressions could
be added for those. Again that could be exhausting API though so, it kind of
depends on how runtime-editable it should be.
> Also the MATCHES test
> is not case-insensitive, and the whole thing is quite verbose. Ideas
> welcome.
Perhaps we can get object-orientated:
populate_target_usage_requirements(
NAME fooRequirements
[PUBLIC|PRIVATE]
INCLUDE_DIRECTORIES "/foo/bar"
INCLUDE_DIRECTORIES "/bat/bug" IF $<CMAKE_BUILD_TYPE> MATCHES Debug
COMPILE_DEFINITIONS "-DQT_CORE_LIB"
COMPILE_DEFINITIONS "-DQT_GUI_LIB" IF BUILD_TESTING
)
add_executable(foo ${ARGS})
set_target_usage_requirements(foo fooRequirements)
...
get_target_usage_requirements(foo someVariable)
test_target_usage_requirement(someVariable
INCLUDE_DIRECTORIES TOUCHES "foo/bar"
OUTPUT myVar
)
if (myVar) ...
test_target_usage_requirement(someVariable
INCLUDE_DIRECTORIES TOUCHES "foo/bar"
IF $<CMAKE_BUILD_TYPE> MATCHES Debug
OUTPUT myVar2
)
if (myVar2) ...
get_target_usage_requirement(someVariable
INCLUDE_DIRECTORIES
IF $<CMAKE_BUILD_TYPE> MATCHES Debug
OUTPUT myVar3
)
list(APPEND myVar3 "blub/bloo")
set_target_usage_requirement(someVariable
INCLUDE_DIRECTORIES ${myVar3}
IF $<CMAKE_BUILD_TYPE> MATCHES Debug
)
Too complex?
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
