summaryrefslogtreecommitdiffstats
path: root/Source/CMakeInstallDestinations.cmake
Commit message (Collapse)AuthorAgeFilesLines
* Utilities/Sphinx: Add option to build and install Info manualOrivej Desh2018-06-121-1/+6
| | | | | Add option `SPHINX_INFO` to enable the Sphinx 'texinfo' builder and use the `makeinfo` tool to convert it to a `.info` file.
* Add installation infix (empty by default)Konstantin Podsvirov2017-01-111-1/+7
|
* Add option to control 'bin' directory of CMake's own installation (#16076)Nicolas BUNEL2016-06-011-0/+5
| | | | | Add a `CMAKE_BIN_DIR` cache entry to CMake's own build configuration. Add a `--bindir` option to the `bootstrap` script to set it.
* QtDialog: Add option to control XDG file install destinationNiels Ole Salscheider2015-12-211-0/+5
| | | | | | | Create a `CMAKE_XDGDATA_DIR` option and add a corresponding flag to the `bootstrap` script. This is needed for multiarch layouts where the prefix is `/usr/${host}` but where architecture-independent files (like the XDG-specific ones) are installed to `/usr/share`.
* Change version scheme to use only two components for feature levelsBrad King2014-02-191-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Historically CMake used three version components for the feature level. We released new features while incrementing only the third version component. Since commit v2.8.2~105^2~4 (New version scheme to support branchy workflow, 2010-04-23) we used the fourth version component for bug-fix releases and the development date: <major>.<minor>.<patch>[.<tweak>][-rc<n>] = Release <major>.<minor>.<patch>.<date>[-<id>] = Development This solidified use of three components for the feature level, and was necessary to continue releasing 2.x versions because: * Some existing projects performed floating-point comparisons of ${CMAKE_MAJOR_VERSION}.${CMAKE_MINOR_VERSION} to 2.x numbers so ``x`` could never be higher than 9. * Version 2.9.<date> was used briefly in post-2.8.0 development in CVS prior to the transition to Git, so using it in releases may have caused confusion. Now that we are moving to 3.x versions, these two restrictions go away. Therefore we now change to use only two components for the feature level and use the scheme: <major>.<minor>.<patch>[-rc<n>] = Release <major>.<minor>.<date>[-<id>] = Development
* Shorten CMake version used in install destinationsBrad King2013-10-251-3/+5
| | | | | | | | | | | | | | | | | | Since commit c9a5f34b (Cleanup use of CMake version in install destinations, 2013-09-26) we use the full CMake version in default install destinations. For rapidly changing versions of the form <major>.<minor>.<patch>.<date>-g<commit>[-dirty] used by developers this is too granular. Instead use just <major>.<minor>.<patch> as the version for default install destinations. This will still be granular enough for unique directories in releases. On Cygwin continue to use the full ${CMake_VERSION} as was the case prior to the above-mentioned commit.
* Cleanup use of CMake version in install destinationsBrad King2013-10-151-0/+36
Factor the CMAKE_DATA_DIR, CMAKE_DOC_DIR, and CMAKE_MAN_DIR selection out of CMakeLists.txt and into a Source/CMakeInstallDestinations.cmake script. Load the script from the original location of the code. Cache the destination values as empty strings so we know if the user sets them explicitly. If not, then compute defaults based on the platform and full CMake version string. By not caching the versioned defaults, we can change them in a single build tree as the version changes. Remove duplication of the install destination defaults from the bootstrap script. Cache empty defaults there too. Parse from the CMake code the default values to report in the help output. Keep the CMake code in a structured format to make this reliable.