Fetch content #446
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| @@ -0,0 +1,60 @@ | ||||||||||
| cmake_minimum_required(VERSION 3.14 FATAL_ERROR) | ||||||||||
|
|
||||||||||
| project( | ||||||||||
| CPM | ||||||||||
| VERSION 0.37.0 | ||||||||||
| LANGUAGES NONE | ||||||||||
| ) | ||||||||||
|
|
||||||||||
| include(CMakePackageConfigHelpers) | ||||||||||
| configure_package_config_file( | ||||||||||
| "${CMAKE_CURRENT_SOURCE_DIR}/cmake/CPMConfig.cmake.in" | ||||||||||
| "${CMAKE_CURRENT_BINARY_DIR}/CPMConfig.cmake" | ||||||||||
| INSTALL_DESTINATION "${CMAKE_INSTALL_LIBDIR}/cmake/CPM" | ||||||||||
|
||||||||||
| ) | ||||||||||
| write_basic_package_version_file( | ||||||||||
| "${CMAKE_CURRENT_BINARY_DIR}/CPMConfigVersion.cmake" COMPATIBILITY SameMajorVersion | ||||||||||
| ARCH_INDEPENDENT | ||||||||||
|
||||||||||
| "${CMAKE_CURRENT_BINARY_DIR}/CPMConfigVersion.cmake" COMPATIBILITY SameMajorVersion | |
| ARCH_INDEPENDENT | |
| "${CMAKE_CURRENT_BINARY_DIR}/CPMConfigVersion.cmake" COMPATIBILITY SameMinorVersion | |
| ARCH_INDEPENDENT |
There was a problem hiding this comment.
Please add a note to remember to change this when there will be CPM v1.0.0. Also wouldn't it make sense to release v1.0.0 with this feature complete and tested? Any other items to be resolved before that can be released?
There was a problem hiding this comment.
I've recently found out about this approach:
.gitattributes and .git_archival.txt (this name is arbitrary).
Basically whenever Github creates the tar ball, it will change the content of .git_archival.txt with appropriate values. E.g.:
- Tagged version:
describe-name: v0.2.0 - Branch version:
describe-name: v0.2.0-9-gc4469f6
Let's go with this approach. We don't need to worry about the versions before this, because you can't use ExternalProject on those versions. Here's a list of the placeholders.
There was a problem hiding this comment.
To test locally, use:
$ git archive --format=tar HEAD --output=test.tar.gzThere was a problem hiding this comment.
@TheLartians As an alternative to hard-coded version numbering, would you agree to such approach, i.e.:
- Read
.git_archival.txtbeforeproject() - Reformat the version to be cmake compliant
- Use this variable as the version number
I have never tried this in a project, but could be very elegant if it can be implemented. Things to confirm:
- cmake accepts this format
-
CPM_MAJOR_VERSIONand so on are extractable - The commit is included in the version and can be retrieved
- It works on patch version branches, i.e. on
v0.38branch after pushing tagv0.38.1it continues to bev0.38.1-1-short_hash, while onmainit carries on withv0.38.0-1-short_hashand so on - Backup method for local development?
There was a problem hiding this comment.
Relevant PR here. For now this approach works because we don't actually build anything. Basically all of this is now compressed to
# Check if there is anything after the allowed format of `vX.Y.Z`, e.g. `vX.Y.Z-rc1`, `vX.Y.Z-9-gc449f6`, etc.
if (GIT_DESCRIBE MATCH "[v]?[0-9\\.]*.+")
set(CPM_RELEASE FALSE)
else ()
set(CPM_RELEASE TRUE)
endif ()
There was a problem hiding this comment.
This may, or may not be useful, i use this for versioning all my builds. Interested to add support for archival as this is new to knowledge to me but I parse the git-describe here. Note the use of EXPR was something I found useful to make it easy to handle all the variants. https://github.com/BareCpper/Version.cmake/blob/38de0dfb1686cfcc0578414587f06e6bcd7415c1/CMake/Version.cmake#L42
There was a problem hiding this comment.
Oh yeah, the regex is wrong because it is not maximally greedy.
That link is overkill though because the major.minor.patch.tweak format is already handled by the project(VERSION) section and the strip from ^([v]?([0-9\\.]+).*) over here, and we only care about if there are additional suffixes like -rc1 of any form. After some thought I think we can simplify it as ^[v]?[0-9\\.]*$ with inverted logic
flagarde marked this conversation as resolved.
Show resolved
Hide resolved
Outdated
There was a problem hiding this comment.
Not really necessary. In my tests, these are not set upstream. I don't understand how but:
CPM_DIR(set in this file) andCURRENT_CPM_VERSION(set in theinclude(cmake/CPM.cmake)) do not propagate upstream- But we can still use the macro/functions defined in
cmake/CPM.cmake
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,5 @@ | ||
| @PACKAGE_INIT@ | ||
|
|
||
| include("${CMAKE_CURRENT_LIST_DIR}/CPM.cmake" NO_POLICY_SCOPE) | ||
|
|
||
| check_required_components(CPM) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not a fan of hardcoding the version in Git as this will require maintainers to be careful when creating new releases that the version and according tag are identical. Additionally the check below will force consumers to use make proper git clones including tags to ensure they are not in a development version.
How about instead using a mechanism like in the publish workflow to publish a downloadable zip archive of the relevant files with the current version on new tags?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would disagree on this. It makes the intent of the versioning more clear. For example, when navigating the git commits, it is easier to know which version the current commit is intended for from the
CMakelists.txtfile. The usual workflow for a release is:Number 2. can be automated in
publishaction to always occur after a release is published. For the case of bug fix increments, those should be branched from the relevant version and merged back into the development branch. For the major version it should be done manually to indicate intent of api change.