CMake/Source/cmGeneratorExpressionParser.cxx: In member function ‘void cmGeneratorExpressionParser::ParseGeneratorExpression(std::vector<cmGeneratorExpressionEvaluator*>&)’:
CMake/Source/cmGeneratorExpressionParser.cxx:116:55: warning: conversion to ‘unsigned int’ from ‘long int’ may alter its value [-Wconversion]
CMake/Source/cmGeneratorExpressionParser.cxx:240:39: warning: conversion to ‘int’ from ‘long int’ may alter its value [-Wconversion]
Generator expressions whose output depends on the configuration
now record that fact. The GetIncludeDirectories method can use
that result to cache the include directories for later calls.
GetIncludeDirectories is called multiple times for a target
for each configuration, so this should restore performance for
multi-config generators.
Following from the discussion here:
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/3615/focus=5170
(Re: Generator expressisons in target properties, 26 Oct 12:10)
we can't split cmTarget API for linking into cmGeneratorTarget. In
the future we will probably also need to move the include and compile
definitions API back to cmTarget so that it can be used by export().
There are two overloads, so that it can use the operational
target when a target property is being evaluated, and a target
can alternatively be specified by name.
At this point, the generators don't chain. That comes later.
The expressions may be parsed and then cached and evaluated multiple
times. They are evaluated lazily so that literals such as ',' can be
treated as universal parameter separators, and can be processed from
results without appearing literally, and without interfering with the
parsing/evaluation of the entire expression.