Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fetch content #446

Open
wants to merge 16 commits into
base: master
Choose a base branch
from
60 changes: 60 additions & 0 deletions CMakeLists.txt
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
Copy link
Member

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?

Copy link

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.txt file. The usual workflow for a release is:

  1. Push a versioned tag with the version marked in the CMakeLists.txt
  2. On next commit, increment version

Number 2. can be automated in publish action 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.

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"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What if we would want to install multiple CPM versions side-by-side, would the previous version be overwritten?
I think the install destination should contain a version specifier as well.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is common practice. The installation via CPMConfig.cmake should in principle be managed by the package manager, in which case you have only 1 version. If you want to install locally multiple versions, you change CMAKE_INSTALL_PREFIX to an appropriate location with the correct version.

Including the verison in the CPMConfig.cmake filename is unsupported on the cmake side afaik.

)
write_basic_package_version_file(
"${CMAKE_CURRENT_BINARY_DIR}/CPMConfigVersion.cmake" COMPATIBILITY SameMajorVersion
ARCH_INDEPENDENT
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Currently we update the minor version on new features, so compatibility should reflect it as well.

Suggested change
"${CMAKE_CURRENT_BINARY_DIR}/CPMConfigVersion.cmake" COMPATIBILITY SameMajorVersion
ARCH_INDEPENDENT
"${CMAKE_CURRENT_BINARY_DIR}/CPMConfigVersion.cmake" COMPATIBILITY SameMinorVersion
ARCH_INDEPENDENT

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

)

# For consumer using FetchContent
if(NOT ${CMAKE_PROJECT_NAME} STREQUAL ${PROJECT_NAME})
# Check if the user download the repo with git and not in an official release
if(EXISTS "${CMAKE_CURRENT_SOURCE_DIR}/.git" AND IS_DIRECTORY "${CMAKE_CURRENT_SOURCE_DIR}/.git")
Copy link

@LecrisUT LecrisUT Mar 2, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.:

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.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To test locally, use:

$ git archive --format=tar HEAD --output=test.tar.gz

Copy link

@LecrisUT LecrisUT Mar 2, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@TheLartians As an alternative to hard-coded version numbering, would you agree to such approach, i.e.:

  • Read .git_archival.txt before project()
  • 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_VERSION and 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.38 branch after pushing tag v0.38.1 it continues to be v0.38.1-1-short_hash, while on main it carries on with v0.38.0-1-short_hash and so on
  • Backup method for local development?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 ()

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

find_package(Git REQUIRED QUIET)
# Generate a git-describe version string from Git repository tags.
execute_process(
COMMAND ${GIT_EXECUTABLE} tag --points-at HEAD
WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}
OUTPUT_VARIABLE CPM_TAG
RESULT_VARIABLE GIT_DESCRIBE_ERROR_CODE
OUTPUT_STRIP_TRAILING_WHITESPACE
)
if(NOT GIT_DESCRIBE_ERROR_CODE AND NOT CPM_TAG STREQUAL "")
set(CPM_RELEASE TRUE)
else()
set(CPM_RELEASE FALSE)
endif()
else()
set(CPM_RELEASE TRUE)
endif()
flagarde marked this conversation as resolved.
Show resolved Hide resolved
# Trick to use the find_package
configure_file(
"${CMAKE_CURRENT_SOURCE_DIR}/cmake/CPM.cmake" "${CMAKE_CURRENT_BINARY_DIR}/CPM.cmake" COPYONLY
)
set(CPM_DIR "${CMAKE_CURRENT_BINARY_DIR}")

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not really necessary. In my tests, these are not set upstream. I don't understand how but:

  • CPM_DIR (set in this file) and CURRENT_CPM_VERSION (set in the include(cmake/CPM.cmake)) do not propagate upstream
  • But we can still use the macro/functions defined in cmake/CPM.cmake

include(cmake/CPM.cmake)
endif()

if(CMAKE_PROJECT_NAME STREQUAL PROJECT_NAME)
# Without it : Unable to determine default CMAKE_INSTALL_LIBDIR directory because no target
# architecture is known. Please enable at least one language before including GNUInstallDirs.
enable_language(C)
include(GNUInstallDirs)
install(
FILES "${CMAKE_CURRENT_BINARY_DIR}/CPMConfig.cmake"
"${CMAKE_CURRENT_BINARY_DIR}/CPMConfigVersion.cmake"
"${CMAKE_CURRENT_SOURCE_DIR}/cmake/CPM.cmake"
DESTINATION "${CMAKE_INSTALL_LIBDIR}/cmake/CPM"
)
endif()
6 changes: 5 additions & 1 deletion cmake/CPM.cmake
Original file line number Diff line number Diff line change
Expand Up @@ -42,7 +42,11 @@ if(NOT COMMAND cpm_message)
endfunction()
endif()

set(CURRENT_CPM_VERSION 1.0.0-development-version)
if(DEFINED CPM_VERSION)
set(CURRENT_CPM_VERSION "${CPM_VERSION}${CPM_DEVELOPMENT}")
else()
set(CURRENT_CPM_VERSION 1.0.0-development-version)
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With the .git_archival.txt we have more details on commit version. Should use that information.

endif()

get_filename_component(CPM_CURRENT_DIRECTORY "${CMAKE_CURRENT_LIST_DIR}" REALPATH)
if(CPM_DIRECTORY)
Expand Down
5 changes: 5 additions & 0 deletions cmake/CPMConfig.cmake.in
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)