summaryrefslogtreecommitdiffstats
path: root/Tests/RunCMake/CMP0026/RunCMakeTest.cmake
Commit message (Collapse)AuthorAgeFilesLines
* CMP0026: Use compatibility codepath until configure is finished (#15748)Stephen Kelly2015-09-181-0/+1
| | | | | | | | | | Use it instead of the similar cmMakefile API. It is necessary to know that the Configure step is completely done, not just that one particular cmMakefile is finished configuring. Prior to commit 611220f7 (cmTarget: Use reliable test for CMP0024 and CMP0026 OLD., 2015-07-25), this was determined by checking whether cmGeneratorTargets exist yet, which happens after the Configure step.
* cmTarget: Compute link language of TARGET_OBJECTS with CMP0026 OLD (#15338)Stephen Kelly2015-01-131-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit v3.1.0-rc1~297^2~5 (cmTarget: Drop 'head' argument from GetSourceFiles, 2014-07-10) exposed a dormant bug in source file computation, causing the test case to regress. After that commit, the source file computation and caching finds an existing container of source files. Prior to that patch, the GetSourceFiles method was called with either a null pointer for the head cmTarget, or it was called with the this pointer. The processSources method is eventually called, which normalizes the difference between the null pointer and the this pointer for the head target. However, the cache key depends on the actual pre-normalized pointer. The change in that commit caused the entry to be found in the cache where it was not before, which resulted in incorrect behavior. Prior to that commit, the test case also fails if the GetSourceFiles overload taking a vector<cmSourceFile*> is changed to normalize the head target at the beginning of the method: cmTarget const* head = head_ ? head_ : this; Such a construct was correctly used in other locations where similar caching was in place, before being removed in commit v3.1.0-rc1~310^2~25 (cmTarget: Remove 'head' argument from GetLinkInformation, 2014-06-12), but is not neccessary anymore. Commit v3.1.0-rc1~674^2~2 (cmTarget: Cache the cmSourceFiles in GetSourceFiles., 2014-04-05) introduced the caching, but fails the test case for an unrelated reason. That unrelated error was introduced in commit v3.1.0-rc1~688^2~5 (cmTarget: Allow any generator expression in SOURCES property., 2014-03-18) and fixed in commit v3.1.0-rc1~561^2~1 (cmTarget: Fix listing of source files at configure-time., 2014-04-13). All commits which fail the test case in the testable way do so when such a cached version of the source files is found and returned at generate time. In the test case, the cached content is populated at configure-time through the use of the deprecated LOCATION property with CMP0026 OLD. The cached content is an empty container for the bar target in the test case, because its source file 'foo.cpp.o' is not known until generate-time. That means that no source files are available to compute the link language and the reported error is issued. The actual problem is that the SourceFilesMap should be cleared after configure time by cmTarget::ClearLinkMaps. Clear it there now.
* cmTarget: Don't assert on object libraries for configure-time location.Stephen Kelly2014-05-061-0/+1
| | | | | | | | | | | | | Commit b8af2011 (cmTarget: Fix listing of source files at configure-time., 2014-04-13) refactored a GetObjectLibrariesCMP0026 method out of GetLanguages. In flight, a conditional use of a target if available was changed to an assert-available. This code is only used to read the LOCATION property at configure time, when the link information is incomplete, and not all targets are defined, so the assert is inappropriate, even though it can lead to incorrect information being generated. CMP0026 warns about the potentially incorrect information anyway.
* cmTarget: Restore <CONFIG>_LOCATION to CMP0026 OLD behavior (#14808)Stephen Kelly2014-03-171-0/+6
| | | | | | | Restore support for the undocumented <CONFIG>_LOCATION target property removed by commit v3.0.0-rc1~175^2 (cmTarget: Remove support for <CONFIG>_LOCATION property, 2013-12-30) as part of the CMP0026 OLD behavior.
* cmTarget: Deprecate the LOCATION target property with a policy.Stephen Kelly2013-10-111-0/+5
The final location and name of a build-target is not determined until generate-time. However, reading the LOCATION property from a target is currently allowed at configure time. Apart from creating possibly-erroneous results, this has an impact on the implementation of cmake itself, and prevents some major cleanups from being made. Disallow reading LOCATION from build-targets with a policy. Port some existing uses of it in CMake itself to use the TARGET_FILE generator expression.