summaryrefslogtreecommitdiffstats
path: root/Source
Commit message (Collapse)AuthorAgeFilesLines
* CMake 2.8.12.1v2.8.12.1Brad King2013-11-051-1/+1
|
* Merge branch 'fix-automoc-compile-definitions' into releaseBrad King2013-11-052-4/+21
|\
| * Automoc: Add directory-level COMPILE_DEFINITIONS to command line (#14535)Stephen Kelly2013-11-052-4/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In commit 18412153 (Refactor cmTarget::GetCompileDefinitions..., 2013-06-06) cmQtAutomoc was refactored to get all compile definitions from the target instead of separately asking the target and querying the directory-level COMPILE_DEFINITIONS property value. While the generation process does integrate directory-level COMPILE_DEFINITIONS into the target definitions, this did not happen until after Automoc targets are constructed. Therefore the commit regressed use of directory-level definitions in Automoc targets. Factor the definition finalization logic out from the cmGlobalGenerator::CreateGeneratorTargets method into a new cmGlobalGenerator::FinalizeTargetCompileDefinitions method and call it before constructing Automoc targets. This will place the directory-level definitions into the target in time to use them for the Automoc targets. Extend the QtAutomoc test to cover this case.
* | Merge branch 'cmake-E-automoc-crash' into releaseBrad King2013-11-051-1/+1
|\ \
| * | cmake: Validate -E cmake_automoc argument count (#14545)Brad King2013-11-051-1/+1
| |/ | | | | | | Do not access an argument index not known to exist.
* | Merge branch 'clear-evaluation-files' into releaseBrad King2013-11-041-0/+8
|\ \
| * | file(GENERATE): Clear internal records between configuresBrad King2013-11-041-0/+8
| |/ | | | | | | | | | | In the CMake interactive dialogs cmGlobalGenerator::Configure may run more than once. Clear the cmGlobalGenerator::EvaluationFiles data between configures to avoid accessing deleted data.
* | Merge branch 'policy-CMP0022-fixes' into releaseBrad King2013-11-044-116/+144
|\ \
| * | Fix summary documentation of INTERFACE_LINK_LIBRARIESBrad King2013-11-041-1/+1
| | | | | | | | | | | | The property applies to all library types, not just shared libraries.
| * | Fix spelling in INTERFACE_LINK_LIBRARIES documentation (#14542)Modestas Vainius2013-11-041-3/+3
| | | | | | | | | | | | s/overriden/overridden/
| * | CMP0022: Warn about a given target at most onceBrad King2013-11-031-2/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since cmTarget::ComputeLinkInterface is called separately for each "head" target that links a target, the warning we produce when CMP0022 is not set could be repeated. Add explicit logic to allow the warning to appear at most once. Multiple copies of the warning for the same target are almost always identical and therefore redundant. In the rare case that two copies of the warning are different, the second can appear in a future run after the first is fixed.
| * | Do not export INTERFACE_LINK_LIBRARIES from non-linkable targetsBrad King2013-11-021-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When cmExportFileGenerator::SetImportLinkInterface exports the old LINK_INTERFACE_LIBRARIES property values it skips doing so for non-linkable targets because target->GetLinkInterface returns NULL for such targets. Since cmExportFileGenerator::PopulateInterfaceLinkLibrariesProperty looks at the INTERFACE_LINK_LIBRARIES property directly instead of using the computed link interface, teach it to skip exporting the property if target->IsLinkable returns false. Extend the RunCMake.CMP0022 test with a case covering this. Simply export an executable target that links to a library that is not exported.
| * | CMP0022: Plain target_link_libraries must populate link interfaceBrad King2013-11-024-140/+122
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The CMP0022 NEW behavior is that the INTERFACE_LINK_LIBRARIES property exactly defines the link interface. The plain target_link_libraries signature says linking is transitive by default, so it should populate the property. Teach the target_link_libraries plain signature to populate the INTERFACE_LINK_LIBRARIES regardless of the CMP0022 setting. Refactor the cmTarget::ComputeLinkInterface checks that warn when the policy is not set to compare the new property to either the explicitly set old link interface properties or the link implementation fallback for all linkable target types, not just static libraries. This fixes a regression in 2.8.12.0 that caused target_link_libraries to not implement transitive linking in the plain signature once the policy CMP0022 is set to NEW.
| * | Merge branch 'output-CMP0022-entries' into policy-CMP0022-fixesBrad King2013-11-021-1/+26
| |\ \
| | * | CMP0022: Output link interface mismatch for static library warningStephen Kelly2013-10-231-1/+26
| | |/ | | | | | | | | | | | | | | | Other warnings for the same policy already have similar output since commit 81d2793e (Add differing target property content to policy CMP0022 warning, 2013-09-11).
| * | Don't add invalid content to static lib INTERFACE_LINK_LIBRARIES.Stephen Kelly2013-10-262-8/+18
| |/ | | | | | | | | | | | | | | | | | | | | | | | | Only valid target names or generator expressions may appear in the target field of a LINK_ONLY expression. Other content like link flags should still be added to that property (wrapped in config-specific generator expressions), but not wrapped in LINK_ONLY. Otherwise undue warnings would be issued for the policy CMP0022. The LINK_ONLY expression only has an effect for actual target names anyway, so there is no logical deficit.
* | Merge branch 'object-library-no-TARGET_FILE' into releaseBrad King2013-11-021-1/+1
|\ \
| * | Genex: Reject $<TARGET_FILE:...> for object libraries (#14532)Brad King2013-11-011-1/+1
| |/ | | | | | | | | | | | | | | | | Teach the cmGeneratorExpressionEvaluator filesystem artifact logic to reject OBJECT_LIBRARY targets since they have no main artifact. Without the explicit rejection evaluation falls through to an internal CMake error message in cmTarget::GetOutputInfo. Extend the RunCMake.GeneratorExpression test to cover these cases.
* | Merge branch 'object-library-missing-source' into releaseBrad King2013-11-021-0/+1
|\ \
| * | Check for OBJECT_LIBRARY source files at start of generationBrad King2013-11-011-0/+1
| |/ | | | | | | | | | | | | Teach cmGlobalGenerator::CheckTargets to include OBJECT_LIBRARY targets in the check for source file existence. Extend the RunCMake.ObjectLibrary test to cover this case.
* | CMake 2.8.12v2.8.12Brad King2013-10-071-1/+1
| |
* | Merge branch 'release'Brad King2013-10-072-4/+4
|\ \ | |/ |/|
| * CMake 2.8.12-rc4Brad King2013-10-011-1/+1
| |
| * Merge branch 'release'Brad King2013-10-012-4/+4
| |\
| | * CMake 2.8.12-rc3Robert Maynard2013-09-091-1/+1
| | |
| | * Merge branch 'release'Robert Maynard2013-09-092-4/+4
| | |\
| | | * CMake 2.8.12-rc2Robert Maynard2013-08-301-1/+1
| | | |
| | | * Merge branch 'release'Robert Maynard2013-08-302-4/+4
| | | |\
| | | | * CMake 2.8.12-rc1Brad King2013-08-152-4/+4
| | | | |
* | | | | Merge topic 'fix-install-include-dirs-processing'Brad King2013-10-071-0/+3
|\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | 6f98f4a Genex: Fix processing multiple include directories for relative paths
| * | | | | 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.
* | | | | | CMake Nightly Date StampKitware Robot2013-10-071-1/+1
|/ / / / /
* | | | | CMake Nightly Date StampKitware Robot2013-10-061-1/+1
| | | | |
* | | | | CMake Nightly Date StampKitware Robot2013-10-051-1/+1
| | | | |
* | | | | CMake Nightly Date StampKitware Robot2013-10-041-1/+1
| | | | |
* | | | | Merge topic 'xcode-5'Brad King2013-10-031-30/+58
|\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | a3194ff Xcode: Fix OBJECT library support for Xcode 5 (#14254) dff8d11 Xcode: Drop XCODE_DEPEND_HELPER for Xcode >= 5 1180322 Xcode: Teach Tests/BuildDepends to allow LINK_DEPENDS_NO_SHARED failure 765b46d Xcode: Fix test architecture selection for Xcode >= 5
| * | | | | Xcode: Fix OBJECT library support for Xcode 5 (#14254)Brad King2013-10-021-19/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Xcode 2.1 through 4 supported $(CURRENT_ARCH) in a PBXFileReference 'path' value used in the "Link Binary with Libraries" build phase. CMake uses this to reference object file locations on link lines to bring in OBJECT library content. However, Xcode 5 now evaluates the $(CURRENT_ARCH) reference in this context as "undefined_arch" so the wrong path is given to the linker. There seems to be no alternative way to produce an architecture-specific value in a PBXFileReference. Fortunately Xcode 5 now also handles link dependencies for paths linked through OTHER_LDFLAGS. For Xcode >= 5, move the OBJECT library object file references from the link build phase to OTHER_LDFLAGS. We can still show the object files in the source group listing in either case.
| * | | | | Xcode: Drop XCODE_DEPEND_HELPER for Xcode >= 5Brad King2013-10-021-12/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Xcode 5.0 now computes dependencies from files linked through OTHER_LDFLAGS, so we no longer need the XCODE_DEPEND_HELPER hack to re-link dependents when targets change.
* | | | | | CMake Nightly Date StampKitware Robot2013-10-031-1/+1
|/ / / / /
* | | | | CMake Nightly Date StampKitware Robot2013-10-021-1/+1
|/ / / /
* | | | Merge topic 'fix-duplicate-custom-commands'Brad King2013-10-011-0/+13
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | dccd494 Use first custom command for the same output (#14446)
| * | | | Use first custom command for the same output (#14446)Brad King2013-09-301-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In buggy code like add_custom_command( OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/out.h MAIN_DEPENDENCY ${CMAKE_CURRENT_SOURCE_DIR}/out.h.in ...) add_custom_command( OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/out.h ...) that has more than one rule to generate the same output CMake has always used the first rule. However, since commit 2268c41a (Optimize custom command full-path dependency lookup, 2013-08-06) we update the map from output to cmSourceFile for every rule generating an output, effectively keeping the last command instead of the first. Fix this regression by checking for each map update if the output already has an entry. If so, keep only the original entry. The VS 8 generator triggers this with a special case for generate.stamp rules that differ between ZERO_CHECK and normal targets, so do not warn for now. Leave a TODO comment for warning in the future.
* | | | | CMake Nightly Date StampKitware Robot2013-10-011-1/+1
| | | | |
* | | | | CMake Nightly Date StampKitware Robot2013-09-301-1/+1
| | | | |
* | | | | CMake Nightly Date StampKitware Robot2013-09-291-1/+1
| | | | |
* | | | | CMake Nightly Date StampKitware Robot2013-09-281-1/+1
| | | | |
* | | | | CMake Nightly Date StampKitware Robot2013-09-271-1/+1
| | | | |
* | | | | CMake Nightly Date StampKitware Robot2013-09-261-1/+1
| | | | |
* | | | | CMake Nightly Date StampKitware Robot2013-09-251-1/+1
| | | | |
* | | | | CMake Nightly Date StampKitware Robot2013-09-241-1/+1
| | | | |