summaryrefslogtreecommitdiffstats
path: root/Source/cmGeneratorExpression.cxx
Commit message (Collapse)AuthorAgeFilesLines
* Convert raw loops to set member insert.Stephen Kelly2015-01-181-6/+2
|
* Use the cmDeleteAll algorithm instead of trivial raw loops.Stephen Kelly2015-01-131-9/+1
|
* cmGeneratorExpression: Remove unused header.Stephen Kelly2014-12-181-2/+0
|
* Fix some Clang -Wstring-conversion warningsSean McBride2014-12-121-1/+1
| | | | | Some false positives, but some flagged faulty asserts where the ! was inside the string instead of outside.
* file(GENERATE): Evaluate early to allow generating source filesStephen Kelly2014-11-121-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | The evaluation files must be known before cmTargetTraceDependencies attempts to find them, but we must actually generate the files after cmTargetTraceDependencies, as that can add to target SOURCES. The limitation is that the generated output name must not depend on the SOURCES of a target if the generated file is used by that target. Mark the output files as GENERATED so that trace dependencies does not expect them to already exist in the filesystem. Move the invokation of ForceLinkerLanguage in the Generate logic to after the generated file names are known. ForceLinkerLanguage tries to determine the sources of a target (in order to determine an already-known language) and otherwise fails to get information about the generated file. Test that the output of file(GENERATE) can be used as a target source file and that accessing the target SOURCES in the name of the output file is an error. Accessing the TARGET_OBJECTS would be a similar error if it was legal to use that generator expression in this context. That is not currently possible and is a different error condition, so test the current error output as a reminder to change the expected output if that becomes possible in the future. Test that generated rule files resulting from cmTargetTraceDependencies appear in the SOURCES generated in the output file.
* Remove borland workarounds.Stephen Kelly2014-10-151-8/+0
| | | | | CMake 3.0 is the last release to require to be able to build with Borland.
* Genex: Track whether an expression depends on the 'head' targetBrad King2014-07-211-0/+3
|
* regex: Use static regexs where possibleBen Boeckel2014-06-091-3/+2
| | | | | Rather than declaring and compiling a constant regex every time a chunk of code is executed, build the regex once.
* cmGeneratorExpression: Add workaround for Borland compilerBrad King2014-06-061-0/+8
|
* backtrace: Convert to local paths in IssueMessageBen Boeckel2014-06-051-1/+1
| | | | | This is the only place we care show the FilePath to the user, so defer the expensive relative path calculation until here.
* genex: remove the need for backtracesBen Boeckel2014-06-051-4/+4
| | | | | Rather than making dummy backtraces and passing them around, just make backtraces optional.
* Features: Add COMPILE_FEATURES generator expression.Stephen Kelly2014-05-211-0/+17
| | | | | | | | | | | | Allow setting build properties based on the features available for a target. The availability of features is determined at generate-time by evaluating the link implementation. Ensure that the <LANG>_STANDARD determined while evaluating COMPILE_FEATURES in the link implementation is not lower than that provided by the INTERFACE of the link implementation. This is similar to handling of transitive properties such as POSITION_INDEPENDENT_CODE.
* Genex: Only evaluate TARGET_OBJECTS to determine target sources.Stephen Kelly2014-04-021-1/+3
| | | | | | | | | | The output of this expression may contain macros for IDEs to replace such as $(Configuration), $(CURRENT_ARCH) etc. To avoid generating content which is not usable in other contexts, report an error if there is an attempt to use it in other contexts. This commit may be reverted in the future if a solution to the above difference is implemented.
* Remove some c_str() calls.Stephen Kelly2014-03-111-1/+1
| | | | | | Use the clang RemoveCStrCalls tool to automatically migrate the code. This was only run on linux, so does not have any positive or negative effect on other platforms.
* stringapi: Pass configuration names as stringsBen Boeckel2014-03-081-2/+2
|
* cmGeneratorExpression: Tokenize over stringsBen Boeckel2014-03-081-8/+8
|
* strings: Remove cmStdString referencesBen Boeckel2014-03-081-1/+1
| | | | | | | | | | | Casts from std::string -> cmStdString were high on the list of things taking up time. Avoid such implicit casts across function calls by just using std::string everywhere. The comment that the symbol name is too long is no longer relevant since modern debuggers alias the templates anyways and the size is a non-issue since the underlying methods are generated since it's inherited.
* cmGeneratorExpression: Improve parsing in StripEmptyListElementsBen Boeckel2014-02-211-3/+10
| | | | | | The char-by-char parsing causes lots of reallocations which shouldn't be necessary. To improve this, fast-path strings without a semicolon, reserve space in the result, and insert into the result in chunks.
* Export: Prefix relative items with genexes in INSTALL_INTERFACE.Stephen Kelly2013-11-261-1/+1
| | | | | | | | | | | | | | Code such as target_include_directories(foo INTERFACE $<INSTALL_INTERFACE:include$<FOO>> ) should be treated as a relative directory, despite the genex, after the INSTALL_INTERFACE is stripped away. Previously, this would generate a relative directory on export, which would be an error on import, so no policy is needed.
* cmTarget: Make GetProperty() const.Stephen Kelly2013-10-311-3/+3
| | | | | | This has follow-on effects for other methods and classes. Further work on making the use of const cmTarget pointers common can be done, particularly with a view to generate-time methods.
* Merge topic 'rename-genex-method'Brad King2013-10-071-3/+3
|\ | | | | | | | | cfae430 Genex: Rename cmGeneratorExpression::NeedsParsing to NeedsEvaluation
| * Genex: Rename cmGeneratorExpression::NeedsParsing to NeedsEvaluationStephen Kelly2013-08-291-3/+3
| |
* | Genex: Fix processing multiple include directories for relative pathsStephen Kelly2013-10-071-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | Re-insert the semicolon which was removed during splitting. Commit d777b8e7 (Genex: Allow relative paths in INSTALL_INTERFACE., 2013-07-25) introduced the prefixItems method to allow relative paths in the argument of the INSTALL_INTERFACE expression. That method was buggy in that it did not re-introduce the semicolon separator in the result. This bug also affects paths which are already absolute in user code.
* | genex: Fix preprocessing with incomplete content (#14410).Stephen Kelly2013-09-131-4/+12
|/ | | | | | | | Similar incomplete generator expressions are already tested in the GeneratorExpression unit test, but those are executed with add_custom_target. The generator expressions in the include directories are run through the preprocessor, whereas the ones run through add_custom_target are not.
* Genex: Allow relative paths in INSTALL_INTERFACE.Stephen Kelly2013-07-251-4/+32
| | | | | | | These paths can be prepended with the ${_IMPORT_PREFIX} generated in the export file. Such relative paths were previously an error.
* Fix cmGeneratorExpression::Preprocess for interleaved inputs.Stephen Kelly2013-03-181-2/+22
| | | | | | | | | | | | | | We can't find both preprocessing expressions at once, because then the BUILD_INTERFACE will always be favored if both are present, even if INSTALL_INTERFACE appears first. This was affecting the behavior of install(EXPORT) because the INTERFACE_INCLUDE_DIRECTORIES contained entries like /foo/include;$<INSTALL_INTERFACE:/bar/include> As the INSTALL_INTERFACE always evaluates to '0', it always needs to be preprocessed properly.
* Restore support for target names with '+' (#13986)Stephen Kelly2013-03-121-1/+1
| | | | | | | | | Extend the range of valid target names with the + sign. This character can commonly be used for target names, such as those containing 'c++'. Add a test but skip it for Borland and Watcom tools which do not support the character. Suggested-By: Benjamin Kloster
* Fix the cmGeneratorExpression::Split when leading chars are present.Stephen Kelly2013-02-281-2/+10
| | | | | | | | | | | | | In the case of input like foo$<1:bar> the preGenex should be 'foo'. In that case, the search for a ';' will not find one, and there is no preceding input to process as a non-genex list. Previously, the result of 'splitting' such a string would instead be a vector containing the same string two times.
* Merge topic 'interface-property-external-read'Brad King2013-02-251-3/+4
|\ | | | | | | | | | | | | | | | | | | 8dfdf1c Fix the tests for evaluating includes and defines. 98a6725 Fix constness of accessors. 7e70744 Expand includes and defines transitively in 'external' genexes. d1a2729 Fix DAG checker finding cycling dependencies. e72eaad Workaround broken code where a target has itself in its link iface. ec2c67b Strip stray semicolons when evaluating generator expressions.
| * Strip stray semicolons when evaluating generator expressions.Stephen Kelly2013-02-181-3/+4
| |
* | Keep track of all targets seen while evaluating a genex.Stephen Kelly2013-02-221-1/+2
|/ | | | | As dependencies of the generator expression, these will re-exported in try_compile generated code.
* Don't keep track of content determined by target property values.Stephen Kelly2013-02-071-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* De-duplicate validation of genex target names.Stephen Kelly2013-02-071-4/+14
|
* Deduplicate the isGeneratorExpression method.Stephen Kelly2013-02-071-0/+13
| | | | This API seems like the most appropriate.
* Cache context-independent includes on evaluation.Stephen Kelly2013-02-031-1/+7
| | | | | | | | | | 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.
* Strip consecutive semicolons when preprocessing genex strings.Stephen Kelly2013-01-151-2/+34
|
* Add cmGeneratorExpression::Split() API.Stephen Kelly2013-01-101-0/+61
| | | | | | | | | | It can split a string like "A;$<1:B>;$<1:C>;D;E;$<1:F;G;H>;$<1:I>;J" into "A" "$<1:B>" "$<1:C>" "D" "E" "$<1:F;G;H>" "$<1:I>" "J"
* Keep track of properties used to determine linker libraries.Stephen Kelly2013-01-081-1/+9
| | | | | Those properties can't later be implicitly defined by the interface of those link libraries.
* Make all relevant targets available in the genex context.Stephen Kelly2013-01-051-2/+18
| | | | | The current node being evaluated transitively in the generator expression must be available to resolve mapped configs.
* GenEx: Add expressions to specify build- or install-only valuesStephen Kelly2013-01-051-8/+80
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Use cmsys::auto_ptr to manage cmCompiledGeneratorExpressionsStephen Kelly2012-12-201-27/+19
| | | | | The compiled generator expressions need to outlive the creating type. For the same reason, store the input string in a std::string.
* Port cmGeneratorExpression to cmTarget from cmGeneratorTarget.Stephen Kelly2012-11-201-1/+1
| | | | | | | | | | | 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().
* GenEx: Fix reporting about not-found include directories and libraries.Stephen Kelly2012-10-171-0/+49
| | | | | | This fixes a regression introduced in commit 290e92ad (Move GetIncludeDirectories to cmGeneratorTarget, 2012-09-16) which loops over cmGeneratorTargets before they get created, so the container is empty.
* Add API to check that dependent target properties form a DAG.Stephen Kelly2012-09-281-2/+4
| | | | | | 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.
* Add a generator expression for target properties.Stephen Kelly2012-09-281-1/+3
| | | | | | | | 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.
* cmGeneratorExpression: Port users to two-stage processingStephen Kelly2012-09-181-26/+39
| | | | | | | | | | Removing the Process() API and removing the parameters from the constructor will allow cmGeneratorExpressions to be cached and evaluated with multiple configs for example, such as when evaluating target properties. This requires the creation of a new compiled representation of cmGeneratorExpression. The cmListFileBacktrace remains in the constructor so that we can record where a particular generator expression appeared in the CMakeLists file.
* cmGeneratorExpression: Re-write for multi-stage evaluationStephen Kelly2012-09-181-187/+53
| | | | | | | | 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.
* Add $<CONFIG:...> boolean query generator expressionBrad King2012-08-151-0/+9
| | | | | | | This expression evaluates to '1' or '0' to indicate whether the build configuration for which the expression is evaluated matches tha named configuration. In combination with the "$<0:...>" and "$<1:...>" expressions this allows per-configuration content to be generated.
* Add boolean generator expressionsBrad King2012-08-151-0/+46
| | | | | | | | | | | | | Add generator expressions that combine and use boolean test results: $<0:...> = empty string (ignores "...") $<1:...> = content of "..." $<AND:?[,?]...> = '1' if all '?' are '1', else '0' $<OR:?[,?]...> = '0' if all '?' are '0', else '1' $<NOT:?> = '0' if '?' is '1', else '1' These will be useful to evaluate (future) boolean query expressions and condition content on the results. Include tests and documentation.
* Allow '.' in target names in generator expressions (#12002)Brad King2011-03-221-1/+1
| | | | | Simply add this character to the allowed list in the regular expression used to parse generator expression components.
generated by cgit v0.12 at 2024-09-01 05:15:52 (GMT)