summaryrefslogtreecommitdiffstats
path: root/Source/CMakeVersionCompute.cmake
Commit message (Collapse)AuthorAgeFilesLines
* CMakeVersion.rc: Avoid leading zeros in integer version componentsBrad King2018-03-091-1/+6
| | | | | | | | The split in commit v3.11.0-rc1~232^2 (CMakeVersion RC file: Split patch into 2 components, 2017-12-01) can leave components "2018,0309", but the latter is an octal constant with digit "9" out of range. Strip the leading zero to express the components as "2018,309" so the resource compiler treats them as decimal.
* CMakeVersion RC file: Split patch into 2 componentsJustin Goshi2017-12-041-0/+10
| | | | | | The binary file version has 4 16-bit components. In cases where the patch component is too large (ex: represents a build date yyyymmdd) we split it into two parts.
* Version: Always define CMake_VERSION_IS_DIRTY to 0 or 1Brad King2016-08-231-0/+1
| | | | | | | | In cmVersionConfig.h we must define this macro with a value because clients expect it to have one. Also ensure that all CMakeLists.txt code paths have an initialized value. Reported-by: Stephen Kelly <steveire@gmail.com>
* Make CMake version dirty state available to codeTobias Hunger2016-07-141-0/+4
| | | | | Set `CMake_VERSION_IS_DIRTY` to 1 or 0 depending on whether the CMake source tree is considered dirty or not.
* Make CMake version suffix available to codeTobias Hunger2016-07-141-4/+8
| | | | Make the string (e.g. "rc1" or "gSHA-dirty") available to the code.
* Change version scheme to use only two components for feature levelsBrad King2014-02-191-5/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Factor CMake version logic into dedicated moduleBrad King2013-10-151-0/+23
Move logic to compute CMake_VERSION out of the top-level CMakeLists.txt file to a dedicated Source/CMakeVersionCompute.cmake module and include it from the original location. This will allow it to be re-used.