kolan
/
CMake
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
CMake/Source/cmGeneratorExpressionEvalua...

1196 lines
40 KiB
C++
Raw Normal View History

cmGeneratorExpression: Re-write for multi-stage evaluation 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.
2012-09-11 21:53:38 +04:00
/*============================================================================
CMake - Cross Platform Makefile Generator
Copyright 2012 Stephen Kelly <steveire@gmail.com>
Distributed under the OSI-approved BSD License (the "License");
see accompanying file Copyright.txt for details.
This software is distributed WITHOUT ANY WARRANTY; without even the
implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
See the License for more information.
============================================================================*/
#include "cmMakefile.h"
#include "cmGeneratorExpressionEvaluator.h"
#include "cmGeneratorExpressionParser.h"
Add API to check that dependent target properties form a DAG. Initially this will only be used to check for self-references, but can be extended to check for cycles when chaining properties of other targets.
2012-09-18 15:42:23 +04:00
#include "cmGeneratorExpressionDAGChecker.h"
Add a self-reference check for target properties. Prevent constructs like: ... INCLUDE_DIRECTORIES "$<TARGET_PROPERTY:INCLUDE_DIRECTORIES>" Indirect self-references (cycles) are also prevented here, but indirect generator expression references of any kind are not possible yet anyway.
2012-09-18 15:53:39 +04:00
#include "cmGeneratorExpression.h"
cmGeneratorExpression: Re-write for multi-stage evaluation 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.
2012-09-11 21:53:38 +04:00
GenEx: Use case insensitive comparison for $<CONFIG:...> This fixes a regression introduced by commit f1eacf0e (cmGeneratorExpression: Re-write for multi-stage evaluation).
2012-11-01 17:21:25 +04:00
#include <cmsys/String.h>
Don't crash when a target is expected but is not available.
2013-01-03 23:56:32 +04:00
#include <assert.h>
cmGeneratorExpression: Re-write for multi-stage evaluation 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.
2012-09-11 21:53:38 +04:00
//----------------------------------------------------------------------------
Attempt to fix the compile of cmake on Sun CC. The problem may be that the reportError method is static, so make it non-static on that platform.
2012-10-12 00:31:35 +04:00
#if !defined(__SUNPRO_CC) || __SUNPRO_CC > 0x510
static
#endif
void reportError(cmGeneratorExpressionContext *context,
cmGeneratorExpression: Re-write for multi-stage evaluation 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.
2012-09-11 21:53:38 +04:00
const std::string &expr, const std::string &result)
{
context->HadError = true;
if (context->Quiet)
{
return;
}
cmOStringStream e;
e << "Error evaluating generator expression:\n"
<< " " << expr << "\n"
<< result;
context->Makefile->GetCMakeInstance()
->IssueMessage(cmake::FATAL_ERROR, e.str().c_str(),
context->Backtrace);
}
//----------------------------------------------------------------------------
struct cmGeneratorExpressionNode
{
virtual ~cmGeneratorExpressionNode() {}
virtual bool GeneratesContent() const { return true; }
Allow generator expressions to require literals.
2012-12-10 14:31:59 +04:00
virtual bool RequiresLiteralInput() const { return false; }
cmGeneratorExpression: Re-write for multi-stage evaluation 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.
2012-09-11 21:53:38 +04:00
virtual bool AcceptsSingleArbitraryContentParameter() const
{ return false; }
virtual int NumExpectedParameters() const { return 1; }
virtual std::string Evaluate(const std::vector<std::string> &parameters,
cmGeneratorExpressionContext *context,
Add API to check that dependent target properties form a DAG. Initially this will only be used to check for self-references, but can be extended to check for cycles when chaining properties of other targets.
2012-09-18 15:42:23 +04:00
const GeneratorExpressionContent *content,
cmGeneratorExpressionDAGChecker *dagChecker
cmGeneratorExpression: Re-write for multi-stage evaluation 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.
2012-09-11 21:53:38 +04:00
) const = 0;
};
//----------------------------------------------------------------------------
static const struct ZeroNode : public cmGeneratorExpressionNode
{
ZeroNode() {}
virtual bool GeneratesContent() const { return false; }
Genex: Ensure that $<0:...> has a parameter.
2012-11-27 01:43:13 +04:00
virtual bool AcceptsSingleArbitraryContentParameter() const { return true; }
cmGeneratorExpression: Re-write for multi-stage evaluation 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.
2012-09-11 21:53:38 +04:00
std::string Evaluate(const std::vector<std::string> &,
cmGeneratorExpressionContext *,
Add API to check that dependent target properties form a DAG. Initially this will only be used to check for self-references, but can be extended to check for cycles when chaining properties of other targets.
2012-09-18 15:42:23 +04:00
const GeneratorExpressionContent *,
cmGeneratorExpressionDAGChecker *) const
cmGeneratorExpression: Re-write for multi-stage evaluation 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.
2012-09-11 21:53:38 +04:00
{
// Unreachable
return std::string();
}
} zeroNode;
//----------------------------------------------------------------------------
static const struct OneNode : public cmGeneratorExpressionNode
{
OneNode() {}
virtual bool AcceptsSingleArbitraryContentParameter() const { return true; }
std::string Evaluate(const std::vector<std::string> &,
cmGeneratorExpressionContext *,
Add API to check that dependent target properties form a DAG. Initially this will only be used to check for self-references, but can be extended to check for cycles when chaining properties of other targets.
2012-09-18 15:42:23 +04:00
const GeneratorExpressionContent *,
cmGeneratorExpressionDAGChecker *) const
cmGeneratorExpression: Re-write for multi-stage evaluation 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.
2012-09-11 21:53:38 +04:00
{
// Unreachable
return std::string();
}
} oneNode;
GenEx: Add expressions to specify build- or install-only values This is for specifying INCLUDE_DIRECTORIES relevant to the build-location or the install location for example: set_property(TARGET foo PROPERTY INTERFACE_INCLUDE_DIRECTORIES "$<BUILD_INTERFACE:${CMAKE_CURRENT_BINARY_DIR};${CMAKE_CURRENT_SOURCE_DIR}>" "$<INSTALL_INTERFACE:${CMAKE_INSTALL_PREFIX}/include>" ) A 'bar' target can then use: set_property(TARGET bar PROPERTY INCLUDE_DIRECTORIES "$<TARGET_PROPERTY:foo,INTERFACE_INCLUDE_DIRECTORIES>" ) and it will work whether foo is in the same project, or an imported target from an installation location, or an imported target from a build location generated by the export() command. Because the generator expressions are only evaluated at build-time, these new expressions are equivalent to the ZeroNode and OneNode. The GeneratorExpression test is split into parts. Some shells can't run the custom command as it is getting too long.
2012-09-23 15:16:44 +04:00
//----------------------------------------------------------------------------
static const struct OneNode buildInterfaceNode;
//----------------------------------------------------------------------------
static const struct ZeroNode installInterfaceNode;
cmGeneratorExpression: Re-write for multi-stage evaluation 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.
2012-09-11 21:53:38 +04:00
//----------------------------------------------------------------------------
#define BOOLEAN_OP_NODE(OPNAME, OP, SUCCESS_VALUE, FAILURE_VALUE) \
static const struct OP ## Node : public cmGeneratorExpressionNode \
{ \
OP ## Node () {} \
/* We let -1 carry the meaning 'at least one' */ \
virtual int NumExpectedParameters() const { return -1; } \
\
std::string Evaluate(const std::vector<std::string> &parameters, \
cmGeneratorExpressionContext *context, \
Add API to check that dependent target properties form a DAG. Initially this will only be used to check for self-references, but can be extended to check for cycles when chaining properties of other targets.
2012-09-18 15:42:23 +04:00
const GeneratorExpressionContent *content, \
cmGeneratorExpressionDAGChecker *) const \
cmGeneratorExpression: Re-write for multi-stage evaluation 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.
2012-09-11 21:53:38 +04:00
{ \
std::vector<std::string>::const_iterator it = parameters.begin(); \
const std::vector<std::string>::const_iterator end = parameters.end(); \
for ( ; it != end; ++it) \
{ \
if (*it == #FAILURE_VALUE) \
{ \
return #FAILURE_VALUE; \
} \
else if (*it != #SUCCESS_VALUE) \
{ \
reportError(context, content->GetOriginalExpression(), \
"Parameters to $<" #OP "> must resolve to either '0' or '1'."); \
return std::string(); \
} \
} \
return #SUCCESS_VALUE; \
} \
} OPNAME;
BOOLEAN_OP_NODE(andNode, AND, 1, 0)
BOOLEAN_OP_NODE(orNode, OR, 0, 1)
#undef BOOLEAN_OP_NODE
//----------------------------------------------------------------------------
static const struct NotNode : public cmGeneratorExpressionNode
{
NotNode() {}
Add API to check that dependent target properties form a DAG. Initially this will only be used to check for self-references, but can be extended to check for cycles when chaining properties of other targets.
2012-09-18 15:42:23 +04:00
cmGeneratorExpression: Re-write for multi-stage evaluation 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.
2012-09-11 21:53:38 +04:00
std::string Evaluate(const std::vector<std::string> &parameters,
cmGeneratorExpressionContext *context,
Add API to check that dependent target properties form a DAG. Initially this will only be used to check for self-references, but can be extended to check for cycles when chaining properties of other targets.
2012-09-18 15:42:23 +04:00
const GeneratorExpressionContent *content,
cmGeneratorExpressionDAGChecker *) const
cmGeneratorExpression: Re-write for multi-stage evaluation 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.
2012-09-11 21:53:38 +04:00
{
if (*parameters.begin() != "0" && *parameters.begin() != "1")
{
reportError(context, content->GetOriginalExpression(),
"$<NOT> parameter must resolve to exactly one '0' or '1' value.");
return std::string();
}
return *parameters.begin() == "0" ? "1" : "0";
}
} notNode;
Extend the generator expression language with more logic. Generator expressions for comparing strings, evaluating strings as booleans, and for creating literal right-angle-brackets and commas are added. Those may be needed in some cases where they appear in literals.
2012-09-12 06:20:42 +04:00
//----------------------------------------------------------------------------
static const struct BoolNode : public cmGeneratorExpressionNode
{
BoolNode() {}
virtual int NumExpectedParameters() const { return 1; }
std::string Evaluate(const std::vector<std::string> &parameters,
cmGeneratorExpressionContext *,
Add API to check that dependent target properties form a DAG. Initially this will only be used to check for self-references, but can be extended to check for cycles when chaining properties of other targets.
2012-09-18 15:42:23 +04:00
const GeneratorExpressionContent *,
cmGeneratorExpressionDAGChecker *) const
Extend the generator expression language with more logic. Generator expressions for comparing strings, evaluating strings as booleans, and for creating literal right-angle-brackets and commas are added. Those may be needed in some cases where they appear in literals.
2012-09-12 06:20:42 +04:00
{
return !cmSystemTools::IsOff(parameters.begin()->c_str()) ? "1" : "0";
}
} boolNode;
//----------------------------------------------------------------------------
static const struct StrEqualNode : public cmGeneratorExpressionNode
{
StrEqualNode() {}
virtual int NumExpectedParameters() const { return 2; }
std::string Evaluate(const std::vector<std::string> &parameters,
cmGeneratorExpressionContext *,
Add API to check that dependent target properties form a DAG. Initially this will only be used to check for self-references, but can be extended to check for cycles when chaining properties of other targets.
2012-09-18 15:42:23 +04:00
const GeneratorExpressionContent *,
cmGeneratorExpressionDAGChecker *) const
Extend the generator expression language with more logic. Generator expressions for comparing strings, evaluating strings as booleans, and for creating literal right-angle-brackets and commas are added. Those may be needed in some cases where they appear in literals.
2012-09-12 06:20:42 +04:00
{
GenEx: Don't use std::vector::at(int). It might not exist with GCC 2.9.
2012-10-04 13:21:05 +04:00
return *parameters.begin() == parameters[1] ? "1" : "0";
Extend the generator expression language with more logic. Generator expressions for comparing strings, evaluating strings as booleans, and for creating literal right-angle-brackets and commas are added. Those may be needed in some cases where they appear in literals.
2012-09-12 06:20:42 +04:00
}
} strEqualNode;
//----------------------------------------------------------------------------
static const struct Angle_RNode : public cmGeneratorExpressionNode
{
Angle_RNode() {}
virtual int NumExpectedParameters() const { return 0; }
std::string Evaluate(const std::vector<std::string> &,
cmGeneratorExpressionContext *,
Add API to check that dependent target properties form a DAG. Initially this will only be used to check for self-references, but can be extended to check for cycles when chaining properties of other targets.
2012-09-18 15:42:23 +04:00
const GeneratorExpressionContent *,
cmGeneratorExpressionDAGChecker *) const
Extend the generator expression language with more logic. Generator expressions for comparing strings, evaluating strings as booleans, and for creating literal right-angle-brackets and commas are added. Those may be needed in some cases where they appear in literals.
2012-09-12 06:20:42 +04:00
{
return ">";
}
} angle_rNode;
//----------------------------------------------------------------------------
static const struct CommaNode : public cmGeneratorExpressionNode
{
CommaNode() {}
virtual int NumExpectedParameters() const { return 0; }
std::string Evaluate(const std::vector<std::string> &,
cmGeneratorExpressionContext *,
Add API to check that dependent target properties form a DAG. Initially this will only be used to check for self-references, but can be extended to check for cycles when chaining properties of other targets.
2012-09-18 15:42:23 +04:00
const GeneratorExpressionContent *,
cmGeneratorExpressionDAGChecker *) const
Extend the generator expression language with more logic. Generator expressions for comparing strings, evaluating strings as booleans, and for creating literal right-angle-brackets and commas are added. Those may be needed in some cases where they appear in literals.
2012-09-12 06:20:42 +04:00
{
return ",";
}
} commaNode;
Add $<SEMICOLON> generator expression. This expression is useful to put a ';' in a command line argument without dividing the argument during CMake list expansion.
2013-03-12 10:52:01 +04:00
//----------------------------------------------------------------------------
static const struct SemicolonNode : public cmGeneratorExpressionNode
{
SemicolonNode() {}
virtual int NumExpectedParameters() const { return 0; }
std::string Evaluate(const std::vector<std::string> &,
cmGeneratorExpressionContext *,
const GeneratorExpressionContent *,
cmGeneratorExpressionDAGChecker *) const
{
return ";";
}
} semicolonNode;
cmGeneratorExpression: Re-write for multi-stage evaluation 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.
2012-09-11 21:53:38 +04:00
//----------------------------------------------------------------------------
static const struct ConfigurationNode : public cmGeneratorExpressionNode
{
ConfigurationNode() {}
Add API to check that dependent target properties form a DAG. Initially this will only be used to check for self-references, but can be extended to check for cycles when chaining properties of other targets.
2012-09-18 15:42:23 +04:00
cmGeneratorExpression: Re-write for multi-stage evaluation 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.
2012-09-11 21:53:38 +04:00
virtual int NumExpectedParameters() const { return 0; }
std::string Evaluate(const std::vector<std::string> &,
cmGeneratorExpressionContext *context,
Add API to check that dependent target properties form a DAG. Initially this will only be used to check for self-references, but can be extended to check for cycles when chaining properties of other targets.
2012-09-18 15:42:23 +04:00
const GeneratorExpressionContent *,
cmGeneratorExpressionDAGChecker *) const
cmGeneratorExpression: Re-write for multi-stage evaluation 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.
2012-09-11 21:53:38 +04:00
{
Cache context-independent includes on evaluation. 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.
2013-02-03 10:33:15 +04:00
context->HadContextSensitiveCondition = true;
cmGeneratorExpression: Re-write for multi-stage evaluation 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.
2012-09-11 21:53:38 +04:00
return context->Config ? context->Config : "";
}
} configurationNode;
//----------------------------------------------------------------------------
static const struct ConfigurationTestNode : public cmGeneratorExpressionNode
{
ConfigurationTestNode() {}
virtual int NumExpectedParameters() const { return 1; }
std::string Evaluate(const std::vector<std::string> &parameters,
cmGeneratorExpressionContext *context,
Add API to check that dependent target properties form a DAG. Initially this will only be used to check for self-references, but can be extended to check for cycles when chaining properties of other targets.
2012-09-18 15:42:23 +04:00
const GeneratorExpressionContent *content,
cmGeneratorExpressionDAGChecker *) const
cmGeneratorExpression: Re-write for multi-stage evaluation 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.
2012-09-11 21:53:38 +04:00
{
cmsys::RegularExpression configValidator;
configValidator.compile("^[A-Za-z0-9_]*$");
if (!configValidator.find(parameters.begin()->c_str()))
{
reportError(context, content->GetOriginalExpression(),
"Expression syntax not recognized.");
return std::string();
}
Cache context-independent includes on evaluation. 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.
2013-02-03 10:33:15 +04:00
context->HadContextSensitiveCondition = true;
GenEx: Ensure that the empty CONFIGURATION can be used conditionally. The CONFIGURATION can not be manipulated at unit testing time, so this is not unit tested further.
2012-10-04 02:36:23 +04:00
if (!context->Config)
{
return parameters.front().empty() ? "1" : "0";
}
Use mapped config properties to evaluate $<CONFIG>
2012-12-23 14:20:37 +04:00
if (cmsysString_strcasecmp(parameters.begin()->c_str(),
context->Config) == 0)
{
return "1";
}
if (context->CurrentTarget
&& context->CurrentTarget->IsImported())
{
const char* loc = 0;
const char* imp = 0;
std::string suffix;
return context->CurrentTarget->GetMappedConfig(context->Config,
&loc,
&imp,
suffix) ? "1" : "0";
}
return "0";
cmGeneratorExpression: Re-write for multi-stage evaluation 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.
2012-09-11 21:53:38 +04:00
}
} configurationTestNode;
Handle INTERFACE properties transitively for includes and defines. Contextually, the behavior is as if the properties content from another target is included in the string and then the result is evaluated.
2012-09-23 15:45:17 +04:00
//----------------------------------------------------------------------------
static const char* targetPropertyTransitiveWhitelist[] = {
"INTERFACE_INCLUDE_DIRECTORIES"
, "INTERFACE_COMPILE_DEFINITIONS"
};
Add a generator expression for target properties. 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.
2012-09-12 06:23:31 +04:00
//----------------------------------------------------------------------------
Add API to check that dependent target properties form a DAG. Initially this will only be used to check for self-references, but can be extended to check for cycles when chaining properties of other targets.
2012-09-18 15:42:23 +04:00
static const struct TargetPropertyNode : public cmGeneratorExpressionNode
Add a generator expression for target properties. 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.
2012-09-12 06:23:31 +04:00
{
TargetPropertyNode() {}
// This node handles errors on parameter count itself.
virtual int NumExpectedParameters() const { return -1; }
std::string Evaluate(const std::vector<std::string> &parameters,
cmGeneratorExpressionContext *context,
Add API to check that dependent target properties form a DAG. Initially this will only be used to check for self-references, but can be extended to check for cycles when chaining properties of other targets.
2012-09-18 15:42:23 +04:00
const GeneratorExpressionContent *content,
Add a self-reference check for target properties. Prevent constructs like: ... INCLUDE_DIRECTORIES "$<TARGET_PROPERTY:INCLUDE_DIRECTORIES>" Indirect self-references (cycles) are also prevented here, but indirect generator expression references of any kind are not possible yet anyway.
2012-09-18 15:53:39 +04:00
cmGeneratorExpressionDAGChecker *dagCheckerParent
) const
Add a generator expression for target properties. 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.
2012-09-12 06:23:31 +04:00
{
if (parameters.size() != 1 && parameters.size() != 2)
{
reportError(context, content->GetOriginalExpression(),
"$<TARGET_PROPERTY:...> expression requires one or two parameters");
return std::string();
}
GexEx: Validate Target names and property names differently. In the unit test, use the same IMPORTED_LOCATION trick that the ExportImport test uses.
2012-10-19 15:11:59 +04:00
cmsys::RegularExpression propertyNameValidator;
propertyNameValidator.compile("^[A-Za-z0-9_]+$");
GenEx: Validate target and property names. They must be non-empty, and match a restrictive regexp.
2012-10-04 02:31:24 +04:00
Make all relevant targets available in the genex context. The current node being evaluated transitively in the generator expression must be available to resolve mapped configs.
2012-11-06 19:06:31 +04:00
cmTarget* target = context->HeadTarget;
Add a generator expression for target properties. 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.
2012-09-12 06:23:31 +04:00
std::string propertyName = *parameters.begin();
Don't crash when a target is expected but is not available.
2013-01-03 23:56:32 +04:00
if (!target && parameters.size() == 1)
{
reportError(context, content->GetOriginalExpression(),
"$<TARGET_PROPERTY:prop> may only be used with targets. It may not "
"be used with add_custom_command. Specify the target to read a "
"property from using the $<TARGET_PROPERTY:tgt,prop> signature "
"instead.");
return std::string();
}
Add a generator expression for target properties. 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.
2012-09-12 06:23:31 +04:00
if (parameters.size() == 2)
{
GenEx: Don't use std::vector::at(int). It might not exist with GCC 2.9.
2012-10-04 13:21:05 +04:00
if (parameters.begin()->empty() && parameters[1].empty())
GenEx: Validate target and property names. They must be non-empty, and match a restrictive regexp.
2012-10-04 02:31:24 +04:00
{
reportError(context, content->GetOriginalExpression(),
"$<TARGET_PROPERTY:tgt,prop> expression requires a non-empty "
"target name and property name.");
return std::string();
}
if (parameters.begin()->empty())
{
reportError(context, content->GetOriginalExpression(),
"$<TARGET_PROPERTY:tgt,prop> expression requires a non-empty "
"target name.");
return std::string();
}
GenEx: Report actual target name not found, not "0" each time.
2012-10-04 02:32:39 +04:00
std::string targetName = parameters.front();
GenEx: Don't use std::vector::at(int). It might not exist with GCC 2.9.
2012-10-04 13:21:05 +04:00
propertyName = parameters[1];
De-duplicate validation of genex target names.
2013-02-06 16:32:15 +04:00
if (!cmGeneratorExpression::IsValidTargetName(targetName))
GenEx: Validate target and property names. They must be non-empty, and match a restrictive regexp.
2012-10-04 02:31:24 +04:00
{
GexEx: Validate Target names and property names differently. In the unit test, use the same IMPORTED_LOCATION trick that the ExportImport test uses.
2012-10-19 15:11:59 +04:00
if (!propertyNameValidator.find(propertyName.c_str()))
GenEx: Validate target and property names. They must be non-empty, and match a restrictive regexp.
2012-10-04 02:31:24 +04:00
{
::reportError(context, content->GetOriginalExpression(),
"Target name and property name not supported.");
return std::string();
}
::reportError(context, content->GetOriginalExpression(),
"Target name not supported.");
return std::string();
}
Port cmGeneratorExpression to cmTarget from cmGeneratorTarget. 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().
2012-10-27 18:16:17 +04:00
target = context->Makefile->FindTargetToUse(
GenEx: Report actual target name not found, not "0" each time.
2012-10-04 02:32:39 +04:00
targetName.c_str());
Add a generator expression for target properties. 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.
2012-09-12 06:23:31 +04:00
if (!target)
{
cmOStringStream e;
e << "Target \""
GenEx: Report actual target name not found, not "0" each time.
2012-10-04 02:32:39 +04:00
<< targetName
Add a generator expression for target properties. 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.
2012-09-12 06:23:31 +04:00
<< "\" not found.";
reportError(context, content->GetOriginalExpression(), e.str());
GenEx: Return after error reported.
2012-10-04 02:32:22 +04:00
return std::string();
Add a generator expression for target properties. 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.
2012-09-12 06:23:31 +04:00
}
Keep track of all targets seen while evaluating a genex. As dependencies of the generator expression, these will re-exported in try_compile generated code.
2013-02-09 14:12:20 +04:00
context->AllTargets.insert(target);
GenEx: Validate target and property names. They must be non-empty, and match a restrictive regexp.
2012-10-04 02:31:24 +04:00
}
Keep track of properties used to determine linker libraries. Those properties can't later be implicitly defined by the interface of those link libraries.
2012-11-05 17:48:42 +04:00
if (target == context->HeadTarget)
{
// Keep track of the properties seen while processing.
// The evaluation of the LINK_LIBRARIES generator expressions
Don't keep track of content determined by target property values. This tracking was added during the development of commit 042ecf04 (Add API to calculate link-interface-dependent bool properties or error., 2013-01-06), but was never used. It was not necessary to use the content because what is really useful in that logic is to determine if a property has been implied to be null by appearing in a LINK_LIBRARIES genex. I think the motivating usecase for developing the feature of keeping track of the targets relevant to a property was that I thought it would make it possible to allow requiring granular compatibility of interface properties only for targets which depended on the interface property. Eg: add_library(foo ...) add_library(bar ...) add_executable(user ...) # Read the INTERFACE_POSITION_INDEPENDENT_CODE from bar, but not # from foo: target_link_libraries(user foo $<$<TARGET_PROPERTY:POSTITION_INDEPENDENT_CODE>:bar>) This obviously doesn't make sense. We require that INTERFACE properties are consistent across all linked targets instead.
2013-02-07 16:04:46 +04:00
// will check this to ensure that properties have one consistent
// value for all evaluations.
Keep track of properties used to determine linker libraries. Those properties can't later be implicitly defined by the interface of those link libraries.
2012-11-05 17:48:42 +04:00
context->SeenTargetProperties.insert(propertyName);
}
GenEx: Validate target and property names. They must be non-empty, and match a restrictive regexp.
2012-10-04 02:31:24 +04:00
if (propertyName.empty())
{
reportError(context, content->GetOriginalExpression(),
"$<TARGET_PROPERTY:...> expression requires a non-empty property "
"name.");
return std::string();
}
GexEx: Validate Target names and property names differently. In the unit test, use the same IMPORTED_LOCATION trick that the ExportImport test uses.
2012-10-19 15:11:59 +04:00
if (!propertyNameValidator.find(propertyName.c_str()))
GenEx: Validate target and property names. They must be non-empty, and match a restrictive regexp.
2012-10-04 02:31:24 +04:00
{
::reportError(context, content->GetOriginalExpression(),
"Property name not supported.");
return std::string();
Add a generator expression for target properties. 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.
2012-09-12 06:23:31 +04:00
}
Add a self-reference check for target properties. Prevent constructs like: ... INCLUDE_DIRECTORIES "$<TARGET_PROPERTY:INCLUDE_DIRECTORIES>" Indirect self-references (cycles) are also prevented here, but indirect generator expression references of any kind are not possible yet anyway.
2012-09-18 15:53:39 +04:00
Don't crash when a target is expected but is not available.
2013-01-03 23:56:32 +04:00
assert(target);
Add a self-reference check for target properties. Prevent constructs like: ... INCLUDE_DIRECTORIES "$<TARGET_PROPERTY:INCLUDE_DIRECTORIES>" Indirect self-references (cycles) are also prevented here, but indirect generator expression references of any kind are not possible yet anyway.
2012-09-18 15:53:39 +04:00
cmGeneratorExpressionDAGChecker dagChecker(context->Backtrace,
target->GetName(),
propertyName,
content,
dagCheckerParent);
Make cycles in target properties ignored, not an error. Constructs such as these are an error as they are direct self-references: set_property(TARGET foo APPEND PROPERTY INCLUDE_DIRECTORIES $<TARGET_PROPERTY:foo,INCLUDE_DIRECTORIES>) set_property(TARGET foo APPEND PROPERTY INCLUDE_DIRECTORIES $<TARGET_PROPERTY:INCLUDE_DIRECTORIES>) However, this is an indirect self-reference in a cycle, and not an error: set_property(TARGET foo APPEND PROPERTY INCLUDE_DIRECTORIES $<TARGET_PROPERTY:bar,INCLUDE_DIRECTORIES>) set_property(TARGET bar APPEND PROPERTY INCLUDE_DIRECTORIES $<TARGET_PROPERTY:foo,INCLUDE_DIRECTORIES>)
2012-12-21 18:49:19 +04:00
switch (dagChecker.check())
Add a self-reference check for target properties. Prevent constructs like: ... INCLUDE_DIRECTORIES "$<TARGET_PROPERTY:INCLUDE_DIRECTORIES>" Indirect self-references (cycles) are also prevented here, but indirect generator expression references of any kind are not possible yet anyway.
2012-09-18 15:53:39 +04:00
{
Make cycles in target properties ignored, not an error. Constructs such as these are an error as they are direct self-references: set_property(TARGET foo APPEND PROPERTY INCLUDE_DIRECTORIES $<TARGET_PROPERTY:foo,INCLUDE_DIRECTORIES>) set_property(TARGET foo APPEND PROPERTY INCLUDE_DIRECTORIES $<TARGET_PROPERTY:INCLUDE_DIRECTORIES>) However, this is an indirect self-reference in a cycle, and not an error: set_property(TARGET foo APPEND PROPERTY INCLUDE_DIRECTORIES $<TARGET_PROPERTY:bar,INCLUDE_DIRECTORIES>) set_property(TARGET bar APPEND PROPERTY INCLUDE_DIRECTORIES $<TARGET_PROPERTY:foo,INCLUDE_DIRECTORIES>)
2012-12-21 18:49:19 +04:00
case cmGeneratorExpressionDAGChecker::SELF_REFERENCE:
Add a self-reference check for target properties. Prevent constructs like: ... INCLUDE_DIRECTORIES "$<TARGET_PROPERTY:INCLUDE_DIRECTORIES>" Indirect self-references (cycles) are also prevented here, but indirect generator expression references of any kind are not possible yet anyway.
2012-09-18 15:53:39 +04:00
dagChecker.reportError(context, content->GetOriginalExpression());
return std::string();
Make cycles in target properties ignored, not an error. Constructs such as these are an error as they are direct self-references: set_property(TARGET foo APPEND PROPERTY INCLUDE_DIRECTORIES $<TARGET_PROPERTY:foo,INCLUDE_DIRECTORIES>) set_property(TARGET foo APPEND PROPERTY INCLUDE_DIRECTORIES $<TARGET_PROPERTY:INCLUDE_DIRECTORIES>) However, this is an indirect self-reference in a cycle, and not an error: set_property(TARGET foo APPEND PROPERTY INCLUDE_DIRECTORIES $<TARGET_PROPERTY:bar,INCLUDE_DIRECTORIES>) set_property(TARGET bar APPEND PROPERTY INCLUDE_DIRECTORIES $<TARGET_PROPERTY:foo,INCLUDE_DIRECTORIES>)
2012-12-21 18:49:19 +04:00
case cmGeneratorExpressionDAGChecker::CYCLIC_REFERENCE:
// No error. We just skip cyclic references.
return std::string();
Optimize genex evaluation for includes and defines. While porting boost to use these features, the generation step took too long (several minutes before I stopped it). The reason was that the boost libraries form a large interdependent mesh. The libraries list their dependencies in their INTERFACE such as: $<LINKED:boost::core>;$<LINKED:boost::config>;$<LINKED:boost::mpl> As boost::core already depends on the boost::config libraries, that expression has no impact on the end-content, as it is removed after the generation step. There is no DAG issue though, so the generator expression evaluation would fully evaluate them. In the case of the config library, it also depends on the core library, so all depends are followed through that again, despite the fact that they've just been evaluated. After this patch, the evaluation skips libraries if they have already been seen via depends or directly in the content. This patch keeps track of targets whose INTERFACE has been consumed already. The INCLUDE_DIRECTORIES and COMPILE_DEFINITIONS properties are whitelisted because repeated content will be stripped out later during generation. For other properties now and in the future, that may not be the case.
2013-02-01 12:38:40 +04:00
case cmGeneratorExpressionDAGChecker::ALREADY_SEEN:
Only use early evaluation termination for transitive properties. We need to make sure expressions which evaluate TARGET_PROPERTY:TYPE multiple times for example get the correct result each time, and not an empty string instead.
2013-02-07 15:33:20 +04:00
for (size_t i = 0;
i < (sizeof(targetPropertyTransitiveWhitelist) /
sizeof(*targetPropertyTransitiveWhitelist));
++i)
{
if (targetPropertyTransitiveWhitelist[i] == propertyName)
{
// No error. We're not going to find anything new here.
return std::string();
}
}
Make cycles in target properties ignored, not an error. Constructs such as these are an error as they are direct self-references: set_property(TARGET foo APPEND PROPERTY INCLUDE_DIRECTORIES $<TARGET_PROPERTY:foo,INCLUDE_DIRECTORIES>) set_property(TARGET foo APPEND PROPERTY INCLUDE_DIRECTORIES $<TARGET_PROPERTY:INCLUDE_DIRECTORIES>) However, this is an indirect self-reference in a cycle, and not an error: set_property(TARGET foo APPEND PROPERTY INCLUDE_DIRECTORIES $<TARGET_PROPERTY:bar,INCLUDE_DIRECTORIES>) set_property(TARGET bar APPEND PROPERTY INCLUDE_DIRECTORIES $<TARGET_PROPERTY:foo,INCLUDE_DIRECTORIES>)
2012-12-21 18:49:19 +04:00
case cmGeneratorExpressionDAGChecker::DAG:
break;
Add a self-reference check for target properties. Prevent constructs like: ... INCLUDE_DIRECTORIES "$<TARGET_PROPERTY:INCLUDE_DIRECTORIES>" Indirect self-references (cycles) are also prevented here, but indirect generator expression references of any kind are not possible yet anyway.
2012-09-18 15:53:39 +04:00
}
Add a generator expression for target properties. 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.
2012-09-12 06:23:31 +04:00
const char *prop = target->GetProperty(propertyName.c_str());
Use the link information as a source of compile definitions and includes. After evaluating the INTERFACE_INCLUDE_DIRECTORIES, of a target in a generator expression, also read the INTERFACE_INCLUDE_DIRECTORIES of its link interface dependencies. That means that code such as this will result in the 'user' target using /bar/include and /foo/include: add_library(foo ...) target_include_directories(foo INTERFACE /foo/include) add_library(bar ...) target_include_directories(bar INTERFACE /bar/include) target_link_libraries(bar LINK_PUBLIC foo) add_executable(user ...) target_include_directories(user PRIVATE $<TARGET_PROPERTY:bar,INTERFACE_INCLUDE_DIRECTORIES>) Also process the interface include directories from direct link dependencies for in-build targets. The situation is similar for the INTERFACE_COMPILE_DEFINITIONS. The include directories related code is currently more complex because we also need to store a backtrace at configure-time for the purpose of debugging includes. The compile definitions related code will use the same pattern in the future. This is not a change in behavior, as existing code has the same effect, but that existing code will be removed in follow-up commits.
2013-02-12 14:29:09 +04:00
if (dagCheckerParent)
Handle INTERFACE properties transitively for includes and defines. Contextually, the behavior is as if the properties content from another target is included in the string and then the result is evaluated.
2012-09-23 15:45:17 +04:00
{
Use the link information as a source of compile definitions and includes. After evaluating the INTERFACE_INCLUDE_DIRECTORIES, of a target in a generator expression, also read the INTERFACE_INCLUDE_DIRECTORIES of its link interface dependencies. That means that code such as this will result in the 'user' target using /bar/include and /foo/include: add_library(foo ...) target_include_directories(foo INTERFACE /foo/include) add_library(bar ...) target_include_directories(bar INTERFACE /bar/include) target_link_libraries(bar LINK_PUBLIC foo) add_executable(user ...) target_include_directories(user PRIVATE $<TARGET_PROPERTY:bar,INTERFACE_INCLUDE_DIRECTORIES>) Also process the interface include directories from direct link dependencies for in-build targets. The situation is similar for the INTERFACE_COMPILE_DEFINITIONS. The include directories related code is currently more complex because we also need to store a backtrace at configure-time for the purpose of debugging includes. The compile definitions related code will use the same pattern in the future. This is not a change in behavior, as existing code has the same effect, but that existing code will be removed in follow-up commits.
2013-02-12 14:29:09 +04:00
if (dagCheckerParent->EvaluatingLinkLibraries())
Make INTERFACE determined properties readable in generator expressions. The properties are evaluated as link-dependent interface properties when evaluating the generator expressions.
2013-01-19 14:21:14 +04:00
{
Use the link information as a source of compile definitions and includes. After evaluating the INTERFACE_INCLUDE_DIRECTORIES, of a target in a generator expression, also read the INTERFACE_INCLUDE_DIRECTORIES of its link interface dependencies. That means that code such as this will result in the 'user' target using /bar/include and /foo/include: add_library(foo ...) target_include_directories(foo INTERFACE /foo/include) add_library(bar ...) target_include_directories(bar INTERFACE /bar/include) target_link_libraries(bar LINK_PUBLIC foo) add_executable(user ...) target_include_directories(user PRIVATE $<TARGET_PROPERTY:bar,INTERFACE_INCLUDE_DIRECTORIES>) Also process the interface include directories from direct link dependencies for in-build targets. The situation is similar for the INTERFACE_COMPILE_DEFINITIONS. The include directories related code is currently more complex because we also need to store a backtrace at configure-time for the purpose of debugging includes. The compile definitions related code will use the same pattern in the future. This is not a change in behavior, as existing code has the same effect, but that existing code will be removed in follow-up commits.
2013-02-12 14:29:09 +04:00
if(!prop)
{
return std::string();
}
Make INTERFACE determined properties readable in generator expressions. The properties are evaluated as link-dependent interface properties when evaluating the generator expressions.
2013-01-19 14:21:14 +04:00
}
Use the link information as a source of compile definitions and includes. After evaluating the INTERFACE_INCLUDE_DIRECTORIES, of a target in a generator expression, also read the INTERFACE_INCLUDE_DIRECTORIES of its link interface dependencies. That means that code such as this will result in the 'user' target using /bar/include and /foo/include: add_library(foo ...) target_include_directories(foo INTERFACE /foo/include) add_library(bar ...) target_include_directories(bar INTERFACE /bar/include) target_link_libraries(bar LINK_PUBLIC foo) add_executable(user ...) target_include_directories(user PRIVATE $<TARGET_PROPERTY:bar,INTERFACE_INCLUDE_DIRECTORIES>) Also process the interface include directories from direct link dependencies for in-build targets. The situation is similar for the INTERFACE_COMPILE_DEFINITIONS. The include directories related code is currently more complex because we also need to store a backtrace at configure-time for the purpose of debugging includes. The compile definitions related code will use the same pattern in the future. This is not a change in behavior, as existing code has the same effect, but that existing code will be removed in follow-up commits.
2013-02-12 14:29:09 +04:00
else
Make INTERFACE determined properties readable in generator expressions. The properties are evaluated as link-dependent interface properties when evaluating the generator expressions.
2013-01-19 14:21:14 +04:00
{
Use the link information as a source of compile definitions and includes. After evaluating the INTERFACE_INCLUDE_DIRECTORIES, of a target in a generator expression, also read the INTERFACE_INCLUDE_DIRECTORIES of its link interface dependencies. That means that code such as this will result in the 'user' target using /bar/include and /foo/include: add_library(foo ...) target_include_directories(foo INTERFACE /foo/include) add_library(bar ...) target_include_directories(bar INTERFACE /bar/include) target_link_libraries(bar LINK_PUBLIC foo) add_executable(user ...) target_include_directories(user PRIVATE $<TARGET_PROPERTY:bar,INTERFACE_INCLUDE_DIRECTORIES>) Also process the interface include directories from direct link dependencies for in-build targets. The situation is similar for the INTERFACE_COMPILE_DEFINITIONS. The include directories related code is currently more complex because we also need to store a backtrace at configure-time for the purpose of debugging includes. The compile definitions related code will use the same pattern in the future. This is not a change in behavior, as existing code has the same effect, but that existing code will be removed in follow-up commits.
2013-02-12 14:29:09 +04:00
assert(dagCheckerParent->EvaluatingIncludeDirectories()
|| dagCheckerParent->EvaluatingCompileDefinitions());
Expand includes and defines transitively in 'external' genexes. This means that we can use expressions of the form $<TARGET_PROPERTY:foo,INTERFACE_INCLUDE_DIRECTORIES> to get a list of the interface include directories of foo, including those coming from dependencies. We can't have a test of a target which has a single include directory in its INCLUDE_DIRECTORIES because the shell on the MSYS platforms transforms a single include directory to include a prefix, which is not what the test expects. We test a target with two directories instead as a means to test a target with no link dependencies.
2013-02-13 15:35:31 +04:00
}
}
std::string linkedTargetsContent;
std::string interfacePropertyName;
Use the link information as a source of compile definitions and includes. After evaluating the INTERFACE_INCLUDE_DIRECTORIES, of a target in a generator expression, also read the INTERFACE_INCLUDE_DIRECTORIES of its link interface dependencies. That means that code such as this will result in the 'user' target using /bar/include and /foo/include: add_library(foo ...) target_include_directories(foo INTERFACE /foo/include) add_library(bar ...) target_include_directories(bar INTERFACE /bar/include) target_link_libraries(bar LINK_PUBLIC foo) add_executable(user ...) target_include_directories(user PRIVATE $<TARGET_PROPERTY:bar,INTERFACE_INCLUDE_DIRECTORIES>) Also process the interface include directories from direct link dependencies for in-build targets. The situation is similar for the INTERFACE_COMPILE_DEFINITIONS. The include directories related code is currently more complex because we also need to store a backtrace at configure-time for the purpose of debugging includes. The compile definitions related code will use the same pattern in the future. This is not a change in behavior, as existing code has the same effect, but that existing code will be removed in follow-up commits.
2013-02-12 14:29:09 +04:00
Expand includes and defines transitively in 'external' genexes. This means that we can use expressions of the form $<TARGET_PROPERTY:foo,INTERFACE_INCLUDE_DIRECTORIES> to get a list of the interface include directories of foo, including those coming from dependencies. We can't have a test of a target which has a single include directory in its INCLUDE_DIRECTORIES because the shell on the MSYS platforms transforms a single include directory to include a prefix, which is not what the test expects. We test a target with two directories instead as a means to test a target with no link dependencies.
2013-02-13 15:35:31 +04:00
if (propertyName == "INTERFACE_INCLUDE_DIRECTORIES"
|| propertyName == "INCLUDE_DIRECTORIES")
{
interfacePropertyName = "INTERFACE_INCLUDE_DIRECTORIES";
}
else if (propertyName == "INTERFACE_COMPILE_DEFINITIONS"
|| propertyName == "COMPILE_DEFINITIONS"
|| strncmp(propertyName.c_str(), "COMPILE_DEFINITIONS_", 20) == 0)
{
interfacePropertyName = "INTERFACE_COMPILE_DEFINITIONS";
}
if (interfacePropertyName == "INTERFACE_INCLUDE_DIRECTORIES"
|| interfacePropertyName == "INTERFACE_COMPILE_DEFINITIONS")
{
const cmTarget::LinkInterface *iface = target->GetLinkInterface(
context->Config,
context->HeadTarget);
if(iface)
{
cmGeneratorExpression ge(context->Backtrace);
Use the link information as a source of compile definitions and includes. After evaluating the INTERFACE_INCLUDE_DIRECTORIES, of a target in a generator expression, also read the INTERFACE_INCLUDE_DIRECTORIES of its link interface dependencies. That means that code such as this will result in the 'user' target using /bar/include and /foo/include: add_library(foo ...) target_include_directories(foo INTERFACE /foo/include) add_library(bar ...) target_include_directories(bar INTERFACE /bar/include) target_link_libraries(bar LINK_PUBLIC foo) add_executable(user ...) target_include_directories(user PRIVATE $<TARGET_PROPERTY:bar,INTERFACE_INCLUDE_DIRECTORIES>) Also process the interface include directories from direct link dependencies for in-build targets. The situation is similar for the INTERFACE_COMPILE_DEFINITIONS. The include directories related code is currently more complex because we also need to store a backtrace at configure-time for the purpose of debugging includes. The compile definitions related code will use the same pattern in the future. This is not a change in behavior, as existing code has the same effect, but that existing code will be removed in follow-up commits.
2013-02-12 14:29:09 +04:00
Expand includes and defines transitively in 'external' genexes. This means that we can use expressions of the form $<TARGET_PROPERTY:foo,INTERFACE_INCLUDE_DIRECTORIES> to get a list of the interface include directories of foo, including those coming from dependencies. We can't have a test of a target which has a single include directory in its INCLUDE_DIRECTORIES because the shell on the MSYS platforms transforms a single include directory to include a prefix, which is not what the test expects. We test a target with two directories instead as a means to test a target with no link dependencies.
2013-02-13 15:35:31 +04:00
std::string sep;
std::string depString;
for (std::vector<std::string>::const_iterator
it = iface->Libraries.begin();
it != iface->Libraries.end(); ++it)
Use the link information as a source of compile definitions and includes. After evaluating the INTERFACE_INCLUDE_DIRECTORIES, of a target in a generator expression, also read the INTERFACE_INCLUDE_DIRECTORIES of its link interface dependencies. That means that code such as this will result in the 'user' target using /bar/include and /foo/include: add_library(foo ...) target_include_directories(foo INTERFACE /foo/include) add_library(bar ...) target_include_directories(bar INTERFACE /bar/include) target_link_libraries(bar LINK_PUBLIC foo) add_executable(user ...) target_include_directories(user PRIVATE $<TARGET_PROPERTY:bar,INTERFACE_INCLUDE_DIRECTORIES>) Also process the interface include directories from direct link dependencies for in-build targets. The situation is similar for the INTERFACE_COMPILE_DEFINITIONS. The include directories related code is currently more complex because we also need to store a backtrace at configure-time for the purpose of debugging includes. The compile definitions related code will use the same pattern in the future. This is not a change in behavior, as existing code has the same effect, but that existing code will be removed in follow-up commits.
2013-02-12 14:29:09 +04:00
{
Workaround broken code where a target has itself in its link iface. There is a test for this since commit 8e756d2b (Tolerate cycles in shared library link interfaces (#12647), 2012-01-12), so make sure it continues to pass, even as we require no self-references in new INTERFACE_ property generator expressions.
2013-02-22 20:16:19 +04:00
if (*it == target->GetName())
{
// Broken code can have a target in its own link interface.
// Don't follow such link interface entries so as not to create a
// self-referencing loop.
continue;
}
Expand includes and defines transitively in 'external' genexes. This means that we can use expressions of the form $<TARGET_PROPERTY:foo,INTERFACE_INCLUDE_DIRECTORIES> to get a list of the interface include directories of foo, including those coming from dependencies. We can't have a test of a target which has a single include directory in its INCLUDE_DIRECTORIES because the shell on the MSYS platforms transforms a single include directory to include a prefix, which is not what the test expects. We test a target with two directories instead as a means to test a target with no link dependencies.
2013-02-13 15:35:31 +04:00
if (context->Makefile->FindTargetToUse(it->c_str()))
Use the link information as a source of compile definitions and includes. After evaluating the INTERFACE_INCLUDE_DIRECTORIES, of a target in a generator expression, also read the INTERFACE_INCLUDE_DIRECTORIES of its link interface dependencies. That means that code such as this will result in the 'user' target using /bar/include and /foo/include: add_library(foo ...) target_include_directories(foo INTERFACE /foo/include) add_library(bar ...) target_include_directories(bar INTERFACE /bar/include) target_link_libraries(bar LINK_PUBLIC foo) add_executable(user ...) target_include_directories(user PRIVATE $<TARGET_PROPERTY:bar,INTERFACE_INCLUDE_DIRECTORIES>) Also process the interface include directories from direct link dependencies for in-build targets. The situation is similar for the INTERFACE_COMPILE_DEFINITIONS. The include directories related code is currently more complex because we also need to store a backtrace at configure-time for the purpose of debugging includes. The compile definitions related code will use the same pattern in the future. This is not a change in behavior, as existing code has the same effect, but that existing code will be removed in follow-up commits.
2013-02-12 14:29:09 +04:00
{
Expand includes and defines transitively in 'external' genexes. This means that we can use expressions of the form $<TARGET_PROPERTY:foo,INTERFACE_INCLUDE_DIRECTORIES> to get a list of the interface include directories of foo, including those coming from dependencies. We can't have a test of a target which has a single include directory in its INCLUDE_DIRECTORIES because the shell on the MSYS platforms transforms a single include directory to include a prefix, which is not what the test expects. We test a target with two directories instead as a means to test a target with no link dependencies.
2013-02-13 15:35:31 +04:00
depString +=
sep + "$<TARGET_PROPERTY:" + *it + ","
+ interfacePropertyName + ">";
sep = ";";
Use the link information as a source of compile definitions and includes. After evaluating the INTERFACE_INCLUDE_DIRECTORIES, of a target in a generator expression, also read the INTERFACE_INCLUDE_DIRECTORIES of its link interface dependencies. That means that code such as this will result in the 'user' target using /bar/include and /foo/include: add_library(foo ...) target_include_directories(foo INTERFACE /foo/include) add_library(bar ...) target_include_directories(bar INTERFACE /bar/include) target_link_libraries(bar LINK_PUBLIC foo) add_executable(user ...) target_include_directories(user PRIVATE $<TARGET_PROPERTY:bar,INTERFACE_INCLUDE_DIRECTORIES>) Also process the interface include directories from direct link dependencies for in-build targets. The situation is similar for the INTERFACE_COMPILE_DEFINITIONS. The include directories related code is currently more complex because we also need to store a backtrace at configure-time for the purpose of debugging includes. The compile definitions related code will use the same pattern in the future. This is not a change in behavior, as existing code has the same effect, but that existing code will be removed in follow-up commits.
2013-02-12 14:29:09 +04:00
}
}
Expand includes and defines transitively in 'external' genexes. This means that we can use expressions of the form $<TARGET_PROPERTY:foo,INTERFACE_INCLUDE_DIRECTORIES> to get a list of the interface include directories of foo, including those coming from dependencies. We can't have a test of a target which has a single include directory in its INCLUDE_DIRECTORIES because the shell on the MSYS platforms transforms a single include directory to include a prefix, which is not what the test expects. We test a target with two directories instead as a means to test a target with no link dependencies.
2013-02-13 15:35:31 +04:00
cmsys::auto_ptr<cmCompiledGeneratorExpression> cge =
ge.Parse(depString);
linkedTargetsContent = cge->Evaluate(context->Makefile,
context->Config,
context->Quiet,
context->HeadTarget,
target,
&dagChecker);
if (cge->GetHadContextSensitiveCondition())
{
context->HadContextSensitiveCondition = true;
}
Use the link information as a source of compile definitions and includes. After evaluating the INTERFACE_INCLUDE_DIRECTORIES, of a target in a generator expression, also read the INTERFACE_INCLUDE_DIRECTORIES of its link interface dependencies. That means that code such as this will result in the 'user' target using /bar/include and /foo/include: add_library(foo ...) target_include_directories(foo INTERFACE /foo/include) add_library(bar ...) target_include_directories(bar INTERFACE /bar/include) target_link_libraries(bar LINK_PUBLIC foo) add_executable(user ...) target_include_directories(user PRIVATE $<TARGET_PROPERTY:bar,INTERFACE_INCLUDE_DIRECTORIES>) Also process the interface include directories from direct link dependencies for in-build targets. The situation is similar for the INTERFACE_COMPILE_DEFINITIONS. The include directories related code is currently more complex because we also need to store a backtrace at configure-time for the purpose of debugging includes. The compile definitions related code will use the same pattern in the future. This is not a change in behavior, as existing code has the same effect, but that existing code will be removed in follow-up commits.
2013-02-12 14:29:09 +04:00
}
}
Strip stray semicolons when evaluating generator expressions.
2013-02-18 14:24:41 +04:00
linkedTargetsContent =
cmGeneratorExpression::StripEmptyListElements(linkedTargetsContent);
Use the link information as a source of compile definitions and includes. After evaluating the INTERFACE_INCLUDE_DIRECTORIES, of a target in a generator expression, also read the INTERFACE_INCLUDE_DIRECTORIES of its link interface dependencies. That means that code such as this will result in the 'user' target using /bar/include and /foo/include: add_library(foo ...) target_include_directories(foo INTERFACE /foo/include) add_library(bar ...) target_include_directories(bar INTERFACE /bar/include) target_link_libraries(bar LINK_PUBLIC foo) add_executable(user ...) target_include_directories(user PRIVATE $<TARGET_PROPERTY:bar,INTERFACE_INCLUDE_DIRECTORIES>) Also process the interface include directories from direct link dependencies for in-build targets. The situation is similar for the INTERFACE_COMPILE_DEFINITIONS. The include directories related code is currently more complex because we also need to store a backtrace at configure-time for the purpose of debugging includes. The compile definitions related code will use the same pattern in the future. This is not a change in behavior, as existing code has the same effect, but that existing code will be removed in follow-up commits.
2013-02-12 14:29:09 +04:00
if (!prop)
{
if (target->IsImported())
{
return linkedTargetsContent;
Make INTERFACE determined properties readable in generator expressions. The properties are evaluated as link-dependent interface properties when evaluating the generator expressions.
2013-01-19 14:21:14 +04:00
}
if (target->IsLinkInterfaceDependentBoolProperty(propertyName,
context->Config))
{
Cache context-independent includes on evaluation. 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.
2013-02-03 10:33:15 +04:00
context->HadContextSensitiveCondition = true;
Make INTERFACE determined properties readable in generator expressions. The properties are evaluated as link-dependent interface properties when evaluating the generator expressions.
2013-01-19 14:21:14 +04:00
return target->GetLinkInterfaceDependentBoolProperty(
propertyName,
context->Config) ? "1" : "0";
}
Add the COMPATIBLE_INTERFACE_STRING property.
2013-01-06 16:49:20 +04:00
if (target->IsLinkInterfaceDependentStringProperty(propertyName,
context->Config))
{
Cache context-independent includes on evaluation. 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.
2013-02-03 10:33:15 +04:00
context->HadContextSensitiveCondition = true;
Handle reading empty properties defined by the link interface. This was segfaulting before.
2013-01-31 14:18:49 +04:00
const char *propContent =
target->GetLinkInterfaceDependentStringProperty(
Add the COMPATIBLE_INTERFACE_STRING property.
2013-01-06 16:49:20 +04:00
propertyName,
context->Config);
Handle reading empty properties defined by the link interface. This was segfaulting before.
2013-01-31 14:18:49 +04:00
return propContent ? propContent : "";
Add the COMPATIBLE_INTERFACE_STRING property.
2013-01-06 16:49:20 +04:00
}
Make INTERFACE determined properties readable in generator expressions. The properties are evaluated as link-dependent interface properties when evaluating the generator expressions.
2013-01-19 14:21:14 +04:00
Use the link information as a source of compile definitions and includes. After evaluating the INTERFACE_INCLUDE_DIRECTORIES, of a target in a generator expression, also read the INTERFACE_INCLUDE_DIRECTORIES of its link interface dependencies. That means that code such as this will result in the 'user' target using /bar/include and /foo/include: add_library(foo ...) target_include_directories(foo INTERFACE /foo/include) add_library(bar ...) target_include_directories(bar INTERFACE /bar/include) target_link_libraries(bar LINK_PUBLIC foo) add_executable(user ...) target_include_directories(user PRIVATE $<TARGET_PROPERTY:bar,INTERFACE_INCLUDE_DIRECTORIES>) Also process the interface include directories from direct link dependencies for in-build targets. The situation is similar for the INTERFACE_COMPILE_DEFINITIONS. The include directories related code is currently more complex because we also need to store a backtrace at configure-time for the purpose of debugging includes. The compile definitions related code will use the same pattern in the future. This is not a change in behavior, as existing code has the same effect, but that existing code will be removed in follow-up commits.
2013-02-12 14:29:09 +04:00
return linkedTargetsContent;
Handle INTERFACE properties transitively for includes and defines. Contextually, the behavior is as if the properties content from another target is included in the string and then the result is evaluated.
2012-09-23 15:45:17 +04:00
}
for (size_t i = 0;
i < (sizeof(targetPropertyTransitiveWhitelist) /
sizeof(*targetPropertyTransitiveWhitelist));
++i)
{
Expand includes and defines transitively in 'external' genexes. This means that we can use expressions of the form $<TARGET_PROPERTY:foo,INTERFACE_INCLUDE_DIRECTORIES> to get a list of the interface include directories of foo, including those coming from dependencies. We can't have a test of a target which has a single include directory in its INCLUDE_DIRECTORIES because the shell on the MSYS platforms transforms a single include directory to include a prefix, which is not what the test expects. We test a target with two directories instead as a means to test a target with no link dependencies.
2013-02-13 15:35:31 +04:00
if (targetPropertyTransitiveWhitelist[i] == interfacePropertyName)
Handle INTERFACE properties transitively for includes and defines. Contextually, the behavior is as if the properties content from another target is included in the string and then the result is evaluated.
2012-09-23 15:45:17 +04:00
{
cmGeneratorExpression ge(context->Backtrace);
Cache context-independent includes on evaluation. 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.
2013-02-03 10:33:15 +04:00
cmsys::auto_ptr<cmCompiledGeneratorExpression> cge = ge.Parse(prop);
std::string result = cge->Evaluate(context->Makefile,
Handle INTERFACE properties transitively for includes and defines. Contextually, the behavior is as if the properties content from another target is included in the string and then the result is evaluated.
2012-09-23 15:45:17 +04:00
context->Config,
context->Quiet,
context->HeadTarget,
target,
&dagChecker);
Cache context-independent includes on evaluation. 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.
2013-02-03 10:33:15 +04:00
if (cge->GetHadContextSensitiveCondition())
{
context->HadContextSensitiveCondition = true;
}
Use the link information as a source of compile definitions and includes. After evaluating the INTERFACE_INCLUDE_DIRECTORIES, of a target in a generator expression, also read the INTERFACE_INCLUDE_DIRECTORIES of its link interface dependencies. That means that code such as this will result in the 'user' target using /bar/include and /foo/include: add_library(foo ...) target_include_directories(foo INTERFACE /foo/include) add_library(bar ...) target_include_directories(bar INTERFACE /bar/include) target_link_libraries(bar LINK_PUBLIC foo) add_executable(user ...) target_include_directories(user PRIVATE $<TARGET_PROPERTY:bar,INTERFACE_INCLUDE_DIRECTORIES>) Also process the interface include directories from direct link dependencies for in-build targets. The situation is similar for the INTERFACE_COMPILE_DEFINITIONS. The include directories related code is currently more complex because we also need to store a backtrace at configure-time for the purpose of debugging includes. The compile definitions related code will use the same pattern in the future. This is not a change in behavior, as existing code has the same effect, but that existing code will be removed in follow-up commits.
2013-02-12 14:29:09 +04:00
if (!linkedTargetsContent.empty())
{
result += (result.empty() ? "" : ";") + linkedTargetsContent;
}
Cache context-independent includes on evaluation. 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.
2013-02-03 10:33:15 +04:00
return result;
Handle INTERFACE properties transitively for includes and defines. Contextually, the behavior is as if the properties content from another target is included in the string and then the result is evaluated.
2012-09-23 15:45:17 +04:00
}
}
return prop;
Add a generator expression for target properties. 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.
2012-09-12 06:23:31 +04:00
}
} targetPropertyNode;
Add the TARGET_NAME generator expression. It will be used as a preprocessing marker.
2012-12-10 14:33:23 +04:00
//----------------------------------------------------------------------------
static const struct TargetNameNode : public cmGeneratorExpressionNode
{
TargetNameNode() {}
virtual bool GeneratesContent() const { return true; }
virtual bool AcceptsSingleArbitraryContentParameter() const { return true; }
virtual bool RequiresLiteralInput() const { return true; }
std::string Evaluate(const std::vector<std::string> &parameters,
cmGeneratorExpressionContext *,
const GeneratorExpressionContent *,
cmGeneratorExpressionDAGChecker *) const
{
return parameters.front();
}
virtual int NumExpectedParameters() const { return 1; }
} targetNameNode;
Add the $<TARGET_POLICY> expression This new expression allows checking how a policy was set when a target was created. That information is only recorded for a subset of policies, so a whitelist is used.
2013-01-16 19:42:39 +04:00
//----------------------------------------------------------------------------
static const char* targetPolicyWhitelist[] = {
"CMP0003"
, "CMP0004"
, "CMP0008"
Automatically link to the qtmain library when linking to QtCore. When using QAxServer, ensure that the qtmain library is excluded by reporting an error at CMake time if it is not.
2012-11-20 17:53:41 +04:00
, "CMP0020"
Add the $<TARGET_POLICY> expression This new expression allows checking how a policy was set when a target was created. That information is only recorded for a subset of policies, so a whitelist is used.
2013-01-16 19:42:39 +04:00
};
cmPolicies::PolicyStatus statusForTarget(cmTarget *tgt, const char *policy)
{
#define RETURN_POLICY(POLICY) \
if (strcmp(policy, #POLICY) == 0) \
{ \
return tgt->GetPolicyStatus ## POLICY (); \
} \
RETURN_POLICY(CMP0003)
RETURN_POLICY(CMP0004)
RETURN_POLICY(CMP0008)
Automatically link to the qtmain library when linking to QtCore. When using QAxServer, ensure that the qtmain library is excluded by reporting an error at CMake time if it is not.
2012-11-20 17:53:41 +04:00
RETURN_POLICY(CMP0020)
Add the $<TARGET_POLICY> expression This new expression allows checking how a policy was set when a target was created. That information is only recorded for a subset of policies, so a whitelist is used.
2013-01-16 19:42:39 +04:00
#undef RETURN_POLICY
assert("!Unreachable code. Not a valid policy");
return cmPolicies::WARN;
}
cmPolicies::PolicyID policyForString(const char *policy_id)
{
#define RETURN_POLICY_ID(POLICY_ID) \
if (strcmp(policy_id, #POLICY_ID) == 0) \
{ \
return cmPolicies:: POLICY_ID; \
} \
RETURN_POLICY_ID(CMP0003)
RETURN_POLICY_ID(CMP0004)
RETURN_POLICY_ID(CMP0008)
Automatically link to the qtmain library when linking to QtCore. When using QAxServer, ensure that the qtmain library is excluded by reporting an error at CMake time if it is not.
2012-11-20 17:53:41 +04:00
RETURN_POLICY_ID(CMP0020)
Add the $<TARGET_POLICY> expression This new expression allows checking how a policy was set when a target was created. That information is only recorded for a subset of policies, so a whitelist is used.
2013-01-16 19:42:39 +04:00
#undef RETURN_POLICY_ID
assert("!Unreachable code. Not a valid policy");
return cmPolicies::CMP0002;
}
//----------------------------------------------------------------------------
static const struct TargetPolicyNode : public cmGeneratorExpressionNode
{
TargetPolicyNode() {}
virtual int NumExpectedParameters() const { return 1; }
std::string Evaluate(const std::vector<std::string> &parameters,
cmGeneratorExpressionContext *context ,
const GeneratorExpressionContent *content,
cmGeneratorExpressionDAGChecker *) const
{
if (!context->HeadTarget)
{
reportError(context, content->GetOriginalExpression(),
"$<TARGET_POLICY:prop> may only be used with targets. It may not "
"be used with add_custom_command.");
return std::string();
}
Cache context-independent includes on evaluation. 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.
2013-02-03 10:33:15 +04:00
context->HadContextSensitiveCondition = true;
Add the $<TARGET_POLICY> expression This new expression allows checking how a policy was set when a target was created. That information is only recorded for a subset of policies, so a whitelist is used.
2013-01-16 19:42:39 +04:00
for (size_t i = 0;
i < (sizeof(targetPolicyWhitelist) /
sizeof(*targetPolicyWhitelist));
++i)
{
const char *policy = targetPolicyWhitelist[i];
if (parameters.front() == policy)
{
cmMakefile *mf = context->HeadTarget->GetMakefile();
switch(statusForTarget(context->HeadTarget, policy))
{
case cmPolicies::WARN:
mf->IssueMessage(cmake::AUTHOR_WARNING,
mf->GetPolicies()->
GetPolicyWarning(policyForString(policy)));
case cmPolicies::REQUIRED_IF_USED:
case cmPolicies::REQUIRED_ALWAYS:
case cmPolicies::OLD:
return "0";
case cmPolicies::NEW:
return "1";
}
}
}
reportError(context, content->GetOriginalExpression(),
"$<TARGET_POLICY:prop> may only be used with a limited number of "
Automatically link to the qtmain library when linking to QtCore. When using QAxServer, ensure that the qtmain library is excluded by reporting an error at CMake time if it is not.
2012-11-20 17:53:41 +04:00
"policies. Currently it may be used with policies CMP0003, CMP0004, "
"CMP0008 and CMP0020."
Add the $<TARGET_POLICY> expression This new expression allows checking how a policy was set when a target was created. That information is only recorded for a subset of policies, so a whitelist is used.
2013-01-16 19:42:39 +04:00
);
return std::string();
}
} targetPolicyNode;
Add the INSTALL_PREFIX genex.
2013-01-27 12:43:44 +04:00
//----------------------------------------------------------------------------
static const struct InstallPrefixNode : public cmGeneratorExpressionNode
{
InstallPrefixNode() {}
Make it an error for INSTALL_PREFIX to be evaluated. An empty string is not likely going to produce expected results in any evaluation context. It is replaced by preprocessing currently.
2013-01-30 20:49:47 +04:00
virtual bool GeneratesContent() const { return true; }
Add the INSTALL_PREFIX genex.
2013-01-27 12:43:44 +04:00
virtual int NumExpectedParameters() const { return 0; }
std::string Evaluate(const std::vector<std::string> &,
Make it an error for INSTALL_PREFIX to be evaluated. An empty string is not likely going to produce expected results in any evaluation context. It is replaced by preprocessing currently.
2013-01-30 20:49:47 +04:00
cmGeneratorExpressionContext *context,
const GeneratorExpressionContent *content,
Add the INSTALL_PREFIX genex.
2013-01-27 12:43:44 +04:00
cmGeneratorExpressionDAGChecker *) const
{
Make it an error for INSTALL_PREFIX to be evaluated. An empty string is not likely going to produce expected results in any evaluation context. It is replaced by preprocessing currently.
2013-01-30 20:49:47 +04:00
reportError(context, content->GetOriginalExpression(),
"INSTALL_PREFIX is a marker for install(EXPORT) only. It "
"should never be evaluated.");
Add the INSTALL_PREFIX genex.
2013-01-27 12:43:44 +04:00
return std::string();
}
} installPrefixNode;
cmGeneratorExpression: Re-write for multi-stage evaluation 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.
2012-09-11 21:53:38 +04:00
//----------------------------------------------------------------------------
template<bool linker, bool soname>
struct TargetFilesystemArtifactResultCreator
{
static std::string Create(cmTarget* target,
cmGeneratorExpressionContext *context,
const GeneratorExpressionContent *content);
};
//----------------------------------------------------------------------------
template<>
struct TargetFilesystemArtifactResultCreator<false, true>
{
static std::string Create(cmTarget* target,
cmGeneratorExpressionContext *context,
const GeneratorExpressionContent *content)
{
// The target soname file (.so.1).
if(target->IsDLLPlatform())
{
::reportError(context, content->GetOriginalExpression(),
"TARGET_SONAME_FILE is not allowed "
"for DLL target platforms.");
return std::string();
}
if(target->GetType() != cmTarget::SHARED_LIBRARY)
{
::reportError(context, content->GetOriginalExpression(),
"TARGET_SONAME_FILE is allowed only for "
"SHARED libraries.");
return std::string();
}
std::string result = target->GetDirectory(context->Config);
result += "/";
result += target->GetSOName(context->Config);
return result;
}
};
//----------------------------------------------------------------------------
template<>
struct TargetFilesystemArtifactResultCreator<true, false>
{
static std::string Create(cmTarget* target,
cmGeneratorExpressionContext *context,
const GeneratorExpressionContent *content)
{
// The file used to link to the target (.so, .lib, .a).
if(!target->IsLinkable())
{
::reportError(context, content->GetOriginalExpression(),
"TARGET_LINKER_FILE is allowed only for libraries and "
"executables with ENABLE_EXPORTS.");
return std::string();
}
return target->GetFullPath(context->Config,
target->HasImportLibrary());
}
};
//----------------------------------------------------------------------------
template<>
struct TargetFilesystemArtifactResultCreator<false, false>
{
static std::string Create(cmTarget* target,
cmGeneratorExpressionContext *context,
const GeneratorExpressionContent *)
{
return target->GetFullPath(context->Config, false, true);
}
};
//----------------------------------------------------------------------------
template<bool dirQual, bool nameQual>
struct TargetFilesystemArtifactResultGetter
{
static std::string Get(const std::string &result);
};
//----------------------------------------------------------------------------
template<>
struct TargetFilesystemArtifactResultGetter<false, true>
{
static std::string Get(const std::string &result)
{ return cmSystemTools::GetFilenameName(result); }
};
//----------------------------------------------------------------------------
template<>
struct TargetFilesystemArtifactResultGetter<true, false>
{
static std::string Get(const std::string &result)
{ return cmSystemTools::GetFilenamePath(result); }
};
//----------------------------------------------------------------------------
template<>
struct TargetFilesystemArtifactResultGetter<false, false>
{
static std::string Get(const std::string &result)
{ return result; }
};
//----------------------------------------------------------------------------
template<bool linker, bool soname, bool dirQual, bool nameQual>
struct TargetFilesystemArtifact : public cmGeneratorExpressionNode
{
TargetFilesystemArtifact() {}
virtual int NumExpectedParameters() const { return 1; }
std::string Evaluate(const std::vector<std::string> &parameters,
cmGeneratorExpressionContext *context,
Add API to check that dependent target properties form a DAG. Initially this will only be used to check for self-references, but can be extended to check for cycles when chaining properties of other targets.
2012-09-18 15:42:23 +04:00
const GeneratorExpressionContent *content,
cmGeneratorExpressionDAGChecker *) const
cmGeneratorExpression: Re-write for multi-stage evaluation 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.
2012-09-11 21:53:38 +04:00
{
// Lookup the referenced target.
std::string name = *parameters.begin();
De-duplicate validation of genex target names.
2013-02-06 16:32:15 +04:00
if (!cmGeneratorExpression::IsValidTargetName(name))
cmGeneratorExpression: Re-write for multi-stage evaluation 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.
2012-09-11 21:53:38 +04:00
{
::reportError(context, content->GetOriginalExpression(),
"Expression syntax not recognized.");
return std::string();
}
cmTarget* target = context->Makefile->FindTargetToUse(name.c_str());
if(!target)
{
::reportError(context, content->GetOriginalExpression(),
"No target \"" + name + "\"");
return std::string();
}
if(target->GetType() >= cmTarget::UTILITY &&
target->GetType() != cmTarget::UNKNOWN_LIBRARY)
{
::reportError(context, content->GetOriginalExpression(),
"Target \"" + name + "\" is not an executable or library.");
return std::string();
}
Keep track of all targets seen while evaluating a genex. As dependencies of the generator expression, these will re-exported in try_compile generated code.
2013-02-09 14:12:20 +04:00
context->DependTargets.insert(target);
context->AllTargets.insert(target);
cmGeneratorExpression: Re-write for multi-stage evaluation 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.
2012-09-11 21:53:38 +04:00
std::string result =
TargetFilesystemArtifactResultCreator<linker, soname>::Create(
target,
context,
content);
if (context->HadError)
{
return std::string();
}
return
TargetFilesystemArtifactResultGetter<dirQual, nameQual>::Get(result);
}
};
//----------------------------------------------------------------------------
static const
TargetFilesystemArtifact<false, false, false, false> targetFileNode;
static const
TargetFilesystemArtifact<true, false, false, false> targetLinkerFileNode;
static const
TargetFilesystemArtifact<false, true, false, false> targetSoNameFileNode;
static const
TargetFilesystemArtifact<false, false, false, true> targetFileNameNode;
static const
TargetFilesystemArtifact<true, false, false, true> targetLinkerFileNameNode;
static const
TargetFilesystemArtifact<false, true, false, true> targetSoNameFileNameNode;
static const
TargetFilesystemArtifact<false, false, true, false> targetFileDirNode;
static const
TargetFilesystemArtifact<true, false, true, false> targetLinkerFileDirNode;
static const
TargetFilesystemArtifact<false, true, true, false> targetSoNameFileDirNode;
//----------------------------------------------------------------------------
static const
cmGeneratorExpressionNode* GetNode(const std::string &identifier)
{
if (identifier == "0")
return &zeroNode;
Replace some 'if' with 'else if' For consistency with the rest of the method.
2012-12-10 14:32:42 +04:00
else if (identifier == "1")
cmGeneratorExpression: Re-write for multi-stage evaluation 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.
2012-09-11 21:53:38 +04:00
return &oneNode;
Replace some 'if' with 'else if' For consistency with the rest of the method.
2012-12-10 14:32:42 +04:00
else if (identifier == "AND")
cmGeneratorExpression: Re-write for multi-stage evaluation 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.
2012-09-11 21:53:38 +04:00
return &andNode;
Replace some 'if' with 'else if' For consistency with the rest of the method.
2012-12-10 14:32:42 +04:00
else if (identifier == "OR")
cmGeneratorExpression: Re-write for multi-stage evaluation 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.
2012-09-11 21:53:38 +04:00
return &orNode;
Replace some 'if' with 'else if' For consistency with the rest of the method.
2012-12-10 14:32:42 +04:00
else if (identifier == "NOT")
cmGeneratorExpression: Re-write for multi-stage evaluation 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.
2012-09-11 21:53:38 +04:00
return &notNode;
else if (identifier == "CONFIGURATION")
return &configurationNode;
else if (identifier == "CONFIG")
return &configurationTestNode;
else if (identifier == "TARGET_FILE")
return &targetFileNode;
else if (identifier == "TARGET_LINKER_FILE")
return &targetLinkerFileNode;
else if (identifier == "TARGET_SONAME_FILE")
return &targetSoNameFileNode;
else if (identifier == "TARGET_FILE_NAME")
return &targetFileNameNode;
else if (identifier == "TARGET_LINKER_FILE_NAME")
return &targetLinkerFileNameNode;
else if (identifier == "TARGET_SONAME_FILE_NAME")
return &targetSoNameFileNameNode;
else if (identifier == "TARGET_FILE_DIR")
return &targetFileDirNode;
else if (identifier == "TARGET_LINKER_FILE_DIR")
return &targetLinkerFileDirNode;
else if (identifier == "TARGET_SONAME_FILE_DIR")
return &targetSoNameFileDirNode;
Extend the generator expression language with more logic. Generator expressions for comparing strings, evaluating strings as booleans, and for creating literal right-angle-brackets and commas are added. Those may be needed in some cases where they appear in literals.
2012-09-12 06:20:42 +04:00
else if (identifier == "STREQUAL")
return &strEqualNode;
else if (identifier == "BOOL")
return &boolNode;
else if (identifier == "ANGLE-R")
return &angle_rNode;
else if (identifier == "COMMA")
return &commaNode;
Add $<SEMICOLON> generator expression. This expression is useful to put a ';' in a command line argument without dividing the argument during CMake list expansion.
2013-03-12 10:52:01 +04:00
else if (identifier == "SEMICOLON")
return &semicolonNode;
Add a generator expression for target properties. 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.
2012-09-12 06:23:31 +04:00
else if (identifier == "TARGET_PROPERTY")
return &targetPropertyNode;
Add the TARGET_NAME generator expression. It will be used as a preprocessing marker.
2012-12-10 14:33:23 +04:00
else if (identifier == "TARGET_NAME")
return &targetNameNode;
Add the $<TARGET_POLICY> expression This new expression allows checking how a policy was set when a target was created. That information is only recorded for a subset of policies, so a whitelist is used.
2013-01-16 19:42:39 +04:00
else if (identifier == "TARGET_POLICY")
return &targetPolicyNode;
GenEx: Add expressions to specify build- or install-only values This is for specifying INCLUDE_DIRECTORIES relevant to the build-location or the install location for example: set_property(TARGET foo PROPERTY INTERFACE_INCLUDE_DIRECTORIES "$<BUILD_INTERFACE:${CMAKE_CURRENT_BINARY_DIR};${CMAKE_CURRENT_SOURCE_DIR}>" "$<INSTALL_INTERFACE:${CMAKE_INSTALL_PREFIX}/include>" ) A 'bar' target can then use: set_property(TARGET bar PROPERTY INCLUDE_DIRECTORIES "$<TARGET_PROPERTY:foo,INTERFACE_INCLUDE_DIRECTORIES>" ) and it will work whether foo is in the same project, or an imported target from an installation location, or an imported target from a build location generated by the export() command. Because the generator expressions are only evaluated at build-time, these new expressions are equivalent to the ZeroNode and OneNode. The GeneratorExpression test is split into parts. Some shells can't run the custom command as it is getting too long.
2012-09-23 15:16:44 +04:00
else if (identifier == "BUILD_INTERFACE")
return &buildInterfaceNode;
else if (identifier == "INSTALL_INTERFACE")
return &installInterfaceNode;
Add the INSTALL_PREFIX genex.
2013-01-27 12:43:44 +04:00
else if (identifier == "INSTALL_PREFIX")
return &installPrefixNode;
cmGeneratorExpression: Re-write for multi-stage evaluation 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.
2012-09-11 21:53:38 +04:00
return 0;
Add a generator expression for target properties. 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.
2012-09-12 06:23:31 +04:00
cmGeneratorExpression: Re-write for multi-stage evaluation 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.
2012-09-11 21:53:38 +04:00
}
//----------------------------------------------------------------------------
GeneratorExpressionContent::GeneratorExpressionContent(
const char *startContent,
unsigned int length)
: StartContent(startContent), ContentLength(length)
{
}
//----------------------------------------------------------------------------
std::string GeneratorExpressionContent::GetOriginalExpression() const
{
return std::string(this->StartContent, this->ContentLength);
}
//----------------------------------------------------------------------------
std::string GeneratorExpressionContent::Evaluate(
Add API to check that dependent target properties form a DAG. Initially this will only be used to check for self-references, but can be extended to check for cycles when chaining properties of other targets.
2012-09-18 15:42:23 +04:00
cmGeneratorExpressionContext *context,
cmGeneratorExpressionDAGChecker *dagChecker) const
cmGeneratorExpression: Re-write for multi-stage evaluation 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.
2012-09-11 21:53:38 +04:00
{
std::string identifier;
{
std::vector<cmGeneratorExpressionEvaluator*>::const_iterator it
= this->IdentifierChildren.begin();
const std::vector<cmGeneratorExpressionEvaluator*>::const_iterator end
= this->IdentifierChildren.end();
for ( ; it != end; ++it)
{
Add API to check that dependent target properties form a DAG. Initially this will only be used to check for self-references, but can be extended to check for cycles when chaining properties of other targets.
2012-09-18 15:42:23 +04:00
identifier += (*it)->Evaluate(context, dagChecker);
cmGeneratorExpression: Re-write for multi-stage evaluation 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.
2012-09-11 21:53:38 +04:00
if (context->HadError)
{
return std::string();
}
}
}
const cmGeneratorExpressionNode *node = GetNode(identifier);
if (!node)
{
reportError(context, this->GetOriginalExpression(),
"Expression did not evaluate to a known generator expression");
return std::string();
}
if (!node->GeneratesContent())
{
Genex: Ensure that $<0:...> has a parameter.
2012-11-27 01:43:13 +04:00
if (node->AcceptsSingleArbitraryContentParameter())
{
if (this->ParamChildren.empty())
{
reportError(context, this->GetOriginalExpression(),
"$<" + identifier + "> expression requires a parameter.");
}
}
else
{
std::vector<std::string> parameters;
this->EvaluateParameters(node, identifier, context, dagChecker,
parameters);
}
cmGeneratorExpression: Re-write for multi-stage evaluation 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.
2012-09-11 21:53:38 +04:00
return std::string();
}
if (node->AcceptsSingleArbitraryContentParameter())
{
std::string result;
std::vector<std::vector<cmGeneratorExpressionEvaluator*> >::const_iterator
pit = this->ParamChildren.begin();
const
std::vector<std::vector<cmGeneratorExpressionEvaluator*> >::const_iterator
pend = this->ParamChildren.end();
for ( ; pit != pend; ++pit)
{
if (!result.empty())
{
result += ",";
}
std::vector<cmGeneratorExpressionEvaluator*>::const_iterator it
= pit->begin();
const std::vector<cmGeneratorExpressionEvaluator*>::const_iterator end
= pit->end();
for ( ; it != end; ++it)
{
Allow generator expressions to require literals.
2012-12-10 14:31:59 +04:00
if (node->RequiresLiteralInput())
{
if ((*it)->GetType() != cmGeneratorExpressionEvaluator::Text)
{
reportError(context, this->GetOriginalExpression(),
"$<" + identifier + "> expression requires literal input.");
return std::string();
}
}
Add API to check that dependent target properties form a DAG. Initially this will only be used to check for self-references, but can be extended to check for cycles when chaining properties of other targets.
2012-09-18 15:42:23 +04:00
result += (*it)->Evaluate(context, dagChecker);
cmGeneratorExpression: Re-write for multi-stage evaluation 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.
2012-09-11 21:53:38 +04:00
if (context->HadError)
{
return std::string();
}
}
}
Allow generator expressions to require literals.
2012-12-10 14:31:59 +04:00
if (node->RequiresLiteralInput())
{
std::vector<std::string> parameters;
parameters.push_back(result);
return node->Evaluate(parameters, context, this, dagChecker);
}
cmGeneratorExpression: Re-write for multi-stage evaluation 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.
2012-09-11 21:53:38 +04:00
return result;
}
std::vector<std::string> parameters;
Genex: Extract a method to parse parameters.
2012-11-27 01:42:00 +04:00
this->EvaluateParameters(node, identifier, context, dagChecker, parameters);
if (context->HadError)
{
return std::string();
}
return node->Evaluate(parameters, context, this, dagChecker);
}
//----------------------------------------------------------------------------
std::string GeneratorExpressionContent::EvaluateParameters(
const cmGeneratorExpressionNode *node,
const std::string &identifier,
cmGeneratorExpressionContext *context,
cmGeneratorExpressionDAGChecker *dagChecker,
std::vector<std::string> &parameters) const
{
cmGeneratorExpression: Re-write for multi-stage evaluation 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.
2012-09-11 21:53:38 +04:00
{
std::vector<std::vector<cmGeneratorExpressionEvaluator*> >::const_iterator
pit = this->ParamChildren.begin();
const
std::vector<std::vector<cmGeneratorExpressionEvaluator*> >::const_iterator
pend = this->ParamChildren.end();
for ( ; pit != pend; ++pit)
{
std::string parameter;
std::vector<cmGeneratorExpressionEvaluator*>::const_iterator it =
pit->begin();
const std::vector<cmGeneratorExpressionEvaluator*>::const_iterator end =
pit->end();
for ( ; it != end; ++it)
{
Add API to check that dependent target properties form a DAG. Initially this will only be used to check for self-references, but can be extended to check for cycles when chaining properties of other targets.
2012-09-18 15:42:23 +04:00
parameter += (*it)->Evaluate(context, dagChecker);
cmGeneratorExpression: Re-write for multi-stage evaluation 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.
2012-09-11 21:53:38 +04:00
if (context->HadError)
{
return std::string();
}
}
parameters.push_back(parameter);
}
}
int numExpected = node->NumExpectedParameters();
if ((numExpected != -1 && (unsigned int)numExpected != parameters.size()))
{
if (numExpected == 0)
{
reportError(context, this->GetOriginalExpression(),
"$<" + identifier + "> expression requires no parameters.");
}
else if (numExpected == 1)
{
reportError(context, this->GetOriginalExpression(),
"$<" + identifier + "> expression requires "
"exactly one parameter.");
}
else
{
cmOStringStream e;
e << "$<" + identifier + "> expression requires "
<< numExpected
<< " comma separated parameters, but got "
<< parameters.size() << " instead.";
reportError(context, this->GetOriginalExpression(), e.str());
}
return std::string();
}
if (numExpected == -1 && parameters.empty())
{
reportError(context, this->GetOriginalExpression(), "$<" + identifier
+ "> expression requires at least one parameter.");
}
Genex: Extract a method to parse parameters.
2012-11-27 01:42:00 +04:00
return std::string();
cmGeneratorExpression: Re-write for multi-stage evaluation 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.
2012-09-11 21:53:38 +04:00
}
//----------------------------------------------------------------------------
static void deleteAll(const std::vector<cmGeneratorExpressionEvaluator*> &c)
{
std::vector<cmGeneratorExpressionEvaluator*>::const_iterator it
= c.begin();
const std::vector<cmGeneratorExpressionEvaluator*>::const_iterator end
= c.end();
for ( ; it != end; ++it)
{
delete *it;
}
}
//----------------------------------------------------------------------------
GeneratorExpressionContent::~GeneratorExpressionContent()
{
deleteAll(this->IdentifierChildren);
typedef std::vector<cmGeneratorExpressionEvaluator*> EvaluatorVector;
typedef std::vector<cmGeneratorExpressionToken> TokenVector;
std::vector<EvaluatorVector>::const_iterator pit =
this->ParamChildren.begin();
const std::vector<EvaluatorVector>::const_iterator pend =
this->ParamChildren.end();
for ( ; pit != pend; ++pit)
{
deleteAll(*pit);
}
}