summaryrefslogtreecommitdiffstats
path: root/Source
Commit message (Collapse)AuthorAgeFilesLines
* cmake-gui: Add search functions to the context menu of the Output widgetMarc Bartholomaeus2013-04-242-0/+21
| | | | Signed-off-by: Alex Neundorf <neundorf@kde.org>
* cmake-gui: Add search functions for Output window (#9733)Marc Bartholomaeus2013-04-242-0/+76
| | | | Signed-off-by: Alex Neundorf <neundorf@kde.org>
* CMake Nightly Date StampKitware Robot2013-04-181-1/+1
|
* Merge topic 'doc-get_filename_component'Brad King2013-04-171-9/+10
|\ | | | | | | | | df71f96 get_filename_component: Document path components more clearly (#14091)
| * get_filename_component: Document path components more clearly (#14091)Brad King2013-04-161-9/+10
| | | | | | | | | | Organize component names in a table to explain each in more detail. Clearly state that PATH is the directory name.
* | Merge topic 'missing-fclose-in-trycompile'Brad King2013-04-171-0/+1
|\ \ | | | | | | | | | | | | ce441fa try_compile: add missing fclose() to recently added error case
| * | try_compile: add missing fclose() to recently added error caseRolf Eike Beer2013-04-161-0/+1
| |/ | | | | | | | | | | | | | | In commit 236133e7 (Handle targets in the LINK_LIBRARIES of try_compile, 2013-02-09) an error return case was added without closing the file in progress. Add the missing fclose() call. Spotted by sevenhill.
* | Merge topic 'fix-clear-INCLUDE_DIRECTORIES-prop'Brad King2013-04-171-0/+4
|\ \ | | | | | | | | | | | | 5a5e0fa Fix clearing of the INCLUDE_DIRECTORIES DIRECTORY property.
| * | Fix clearing of the INCLUDE_DIRECTORIES DIRECTORY property.Stephen Kelly2013-04-101-0/+4
| | | | | | | | | | | | | | | This was broken by commit 18a3195a (Keep track of INCLUDE_DIRECTORIES as a vector of structs., 2012-11-19).
* | | CMake Nightly Date StampKitware Robot2013-04-171-1/+1
| |/ |/|
* | CMake Nightly Date StampKitware Robot2013-04-161-1/+1
| |
* | CMake Nightly Date StampKitware Robot2013-04-151-1/+1
| |
* | CMake Nightly Date StampKitware Robot2013-04-141-1/+1
| |
* | CMake Nightly Date StampKitware Robot2013-04-131-1/+1
| |
* | CMake Nightly Date StampKitware Robot2013-04-121-1/+1
| |
* | CMake Nightly Date StampKitware Robot2013-04-111-1/+1
| |
* | CMake Nightly Date StampKitware Robot2013-04-101-1/+1
|/
* CMake Nightly Date StampKitware Robot2013-04-091-1/+1
|
* CMake Nightly Date StampKitware Robot2013-04-081-1/+1
|
* CMake Nightly Date StampKitware Robot2013-04-071-1/+1
|
* CMake Nightly Date StampKitware Robot2013-04-061-1/+1
|
* CMake Nightly Date StampKitware Robot2013-04-051-1/+1
|
* Merge topic 'usr-move-relocatable'Brad King2013-04-041-23/+26
|\ | | | | | | | | 6c613b4 Handle usr-move without forcing absolute paths (#14041)
| * Handle usr-move without forcing absolute paths (#14041)Brad King2013-04-031-23/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In commit 0c727b90 (install(EXPORT): Force absolute paths for usr-move, 2013-03-08) and commit d4774140 (configure_package_config_file: force absolute paths for usr-move, 2013-01-24) we supported Linux distributions implementing the "/usr move" by assuming that installation to (/usr)?/lib(64)? represents a non-relocatable system package. When cross-compiling one may prepare a package for installation into a system location on a target machine but install the package files on the *host* machine inside another path for use with CMAKE_FIND_ROOT_PATH. In this case the package development files must still be relocatable. Handle "/usr move" with a new approach that works with relocatable files. Teach configure_package_config_file and install(EXPORT) to generate special logic in a package configuration file or targets file for installation under (/usr)?/lib(64)?. Teach the file to recognize when it is loaded through a symlink that refers to the same realpath as its original install destination. In such a case, use the original install prefix. Otherwise, compute the prefix relative to the current file location to make it relocatable.
* | CMake Nightly Date StampKitware Robot2013-04-041-1/+1
|/
* CMake Nightly Date StampKitware Robot2013-04-031-1/+1
|
* Merge topic 'automoc-vs11-workaround'Brad King2013-04-021-8/+42
|\ | | | | | | | | 20c99b1 automoc: Use a pre-build event in VS >= 7
| * automoc: Use a pre-build event in VS >= 7Brad King2013-03-291-8/+42
| | | | | | | | | | | | | | | | | | | | In VS IDE generators add a pre-build event to perform automoc instead of using a separate custom target. This reduces the number of targets in the .sln that need to be loaded by the IDE. This also works around a VS 11 bug as discussed in issue 13900. Suggested-by: Hauke Heibel <hauke.heibel@gmail.com>
* | Merge topic 'clarify-add_dependencies-error'Brad King2013-04-021-4/+8
|\ \ | | | | | | | | | | | | de13d68 add_dependencies: Distinguish target v. file dependencies in error (#14050)
| * | add_dependencies: Distinguish target v. file dependencies in error (#14050)Brad King2013-03-291-4/+8
| | | | | | | | | | | | | | | | | | | | | When called with a non-existent LHS target name the user may be trying to add file-level dependencies. Clarify the error message to explain the difference between target-level and file-level dependencies. Point the reader at the commands and options needed for the latter.
* | | CMake Nightly Date StampKitware Robot2013-04-021-1/+1
| | |
* | | CMake Nightly Date StampKitware Robot2013-04-011-1/+1
| | |
* | | CMake Nightly Date StampKitware Robot2013-03-311-1/+1
| | |
* | | CMake Nightly Date StampKitware Robot2013-03-301-1/+1
| |/ |/|
* | CMake Nightly Date StampKitware Robot2013-03-291-1/+1
|/
* Merge topic 'SystemTools-TrimWhitespace-all'Brad King2013-03-281-2/+2
|\ | | | | | | | | 674f918 cmSystemTools: Generalize TrimWhitespace to all whitespace
| * cmSystemTools: Generalize TrimWhitespace to all whitespacePetr Kmoch2013-03-271-2/+2
| | | | | | | | | | Modify cmSystemTools::TrimWhitespace() to remove all leading and trailing whitespace, not just spaces.
* | Merge topic 'error-on-exported-missing-include-dir'Brad King2013-03-281-0/+14
|\ \ | | | | | | | | | | | | 634bb33 Error if linked target has relative paths in INTERFACE_INCLUDE_DIRECTORIES
| * | Error if linked target has relative paths in INTERFACE_INCLUDE_DIRECTORIESStephen Kelly2013-03-261-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | We can do this check only if the TargetName is non-empty, which means that we're evaluating INTERFACE_INCLUDE_DIRECTORIES from a linked dependency which was set using target_link_libraries. It is possible to have relative paths in INCLUDE_DIRECTORIES already in CMake 2.8.10.2, so that part will require a policy to fix.
* | | CMake Nightly Date StampKitware Robot2013-03-281-1/+1
| | |
* | | CMake Nightly Date StampKitware Robot2013-03-271-1/+1
| |/ |/|
* | Merge topic 'error-on-exported-missing-include-dir'Brad King2013-03-264-5/+145
|\ \ | |/ | | | | | | | | 28051f1 Report an error on IMPORTED targets with a faulty INTERFACE af81a3c install(EXPORT): Ensure clean INTERFACE_INCLUDE_DIRECTORIES
| * Report an error on IMPORTED targets with a faulty INTERFACEStephen Kelly2013-03-261-3/+28
| | | | | | | | | | | | | | | | | | | | It is considered an error if the INTERFACE_INCLUDE_DIRECTORIES contains a directory which does not exist, which indicates a programmer error by the upstream, or a packaging error. One of the RunCMake.CompatibleInterface tests also needs to be updated due to this change. Non-existant includes were used in the test, but are not needed.
| * install(EXPORT): Ensure clean INTERFACE_INCLUDE_DIRECTORIESStephen Kelly2013-03-263-2/+117
| | | | | | | | | | | | | | | | | | | | Check that source and binary directories are not part of the INTERFACE_INCLUDE_DIRECTORIES for installed IMPORTED targets. This is limited to directories which do not contain generator expressions to evaluate. Such paths can only be checked at time of use of the imported target, which will be done in a follow up patch.
* | Merge topic 'vs-sln-header'Brad King2013-03-262-2/+16
|\ \ | | | | | | | | | | | | c677838 VS: Fix VS 10/11 .sln headers (#14038)
| * | VS: Fix VS 10/11 .sln headers (#14038)Brad King2013-03-252-2/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The VS version we generate in the .sln header is used by VS when opening the file through Windows Explorer and possibly elsewhere. Fix our generators to use version strings known to VS to avoid a drop-down box. For VS 10, since commit 4f96af44 (Fix VS 10 .sln files for Windows Explorer, 2009-10-22) we use "Visual Studio 2010" instead of just "Visual Studio 10". This is correct except that for the Express edition we need "Visual C++ Express 2010". For VS 11, since commit f0d66ab4 (VS11: Fix comment generated at the top of *.sln files, 2011-10-20) we use "Visual Studio 11" in the .sln header but the preferred value is "Visual Studio 2012" (just as the first commit mentioned above fixed for VS 10). Also for the Express edition we need "Visual Studio Express 2012 for Windows Desktop".
* | | Merge topic 'fix-new-target-commands-docs'Brad King2013-03-262-7/+4
|\ \ \ | | | | | | | | | | | | | | | | 2e80f9f Fix new target commands documentation.
| * | | Fix new target commands documentation.Stephen Kelly2013-03-252-7/+4
| | |/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The target_include_directories and target_compile_defintions commands accepted targets as arguments until commit f6b16d4b (Don't allow targets args in the new target commands., 2013-01-29). This followed from discussion on the mailing list (target_include_directories() accepts only absolute paths ?, 2013-01-28): http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/5925/focus=5948 http://public.kitware.com/pipermail/cmake-developers/2013-January/006301.html It was also decided to allow relative paths in target_include_directories().
* | | Merge topic 'fix-COMPILE_DEFINITIONS-config'Brad King2013-03-2612-39/+26
|\ \ \ | | | | | | | | | | | | | | | | | | | | 1703b00 Test evaluation of per-config COMPILE_DEFINITIONS (#14037) a6286e9 Fix the evaluation of per-config COMPILE_DEFINITIONS (#14037)
| * | | Fix the evaluation of per-config COMPILE_DEFINITIONS (#14037)Stephen Kelly2013-03-2512-39/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The API for retrieving per-config COMPILE_DEFINITIONS has long existed because of the COMPILE_DEFINITIONS_<CONFIG> style properties. Ensure that the provided configuration being generated is also used to evaluate the generator expressions in cmTarget::GetCompileDefinitions. Both the generic COMPILE_DEFINITIONS and the config-specific variant need to be evaluated with the requested configuration. This has the side-effect that the COMPILE_DEFINITIONS does not need to be additionally evaluated with no configuration, so the callers can be cleaned up a bit too.