MantisBT - CMake | ||||||||||
View Issue Details | ||||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | |||||
0015222 | CMake | CMake | public | 2014-10-28 08:08 | 2016-06-10 14:31 | |||||
Reporter | Charles Karney | |||||||||
Assigned To | Kitware Robot | |||||||||
Priority | normal | Severity | feature | Reproducibility | always | |||||
Status | closed | Resolution | moved | |||||||
Platform | OS | OS Version | ||||||||
Product Version | CMake 3.0.2 | |||||||||
Target Version | Fixed in Version | |||||||||
Summary | 0015222: Need a way to determine when features were introduced into cmake | |||||||||
Description | Authors of cmake scripts face a challenge ensuring that their scripts are portable. This is exacerbated by * cmake is constantly evolving (which is good!); * their cmake scripts are run by a diverse set of users (also good!); * authors have little control over the version of cmake that end-users have installed; * the relationship with end-users is even more tenuous with the package-config scripts (which are not read by the builder of the package but by a developer using the package). There is cmake_minimum_required, but authors would normally not want to set this to too recent a version. The problem is that it's difficult to know when a particular feature appeared in cmake. There's no single changelog (and the format of the changelog doesn't make it easy to search in). Frequently I'm left doing a binary search in the documentation! Sometimes I need install old versions to check their behavior. For example I just noticed that install (TARGET ...) also an INCLUDES DESTINATION option. This seemed like a feature I should be using until I noticed that it only appeared in 2.8.12 (or thereabouts). Suggestions: * Have a developer mode where cmake behaves as though it were at the version given by cmake_minimum_required. (Probably this is unfeasible?) * In the documentation, specify when each command, command option, variable, etc., was introduced. (Might junk up the documentation.) * Split this information off into a separate document. (My favored solution.) | |||||||||
Steps To Reproduce | N/A | |||||||||
Additional Information | N/A | |||||||||
Tags | No tags attached. | |||||||||
Relationships |
| |||||||||
Attached Files | ||||||||||
Issue History | ||||||||||
Date Modified | Username | Field | Change | |||||||
2014-10-28 08:08 | Charles Karney | New Issue | ||||||||
2014-10-28 08:40 | Brad King | Note Added: 0037079 | ||||||||
2014-10-28 17:17 | Stephen Kelly | Note Added: 0037092 | ||||||||
2014-10-28 18:16 | Charles Karney | Note Added: 0037093 | ||||||||
2015-04-16 12:31 | Brad King | Relationship added | has duplicate 0015517 | |||||||
2016-06-10 14:29 | Kitware Robot | Note Added: 0042652 | ||||||||
2016-06-10 14:29 | Kitware Robot | Status | new => resolved | |||||||
2016-06-10 14:29 | Kitware Robot | Resolution | open => moved | |||||||
2016-06-10 14:29 | Kitware Robot | Assigned To | => Kitware Robot | |||||||
2016-06-10 14:31 | Kitware Robot | Status | resolved => closed |
Notes | |||||
|
|||||
|
|
||||
|
|||||
|
|
||||
|
|||||
|
|
||||
|
|||||
|
|