Skip to content

Include git hash in package lock comment for unversioned packages #315

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

Open
Astiolo opened this issue Dec 24, 2021 · 4 comments
Open

Include git hash in package lock comment for unversioned packages #315

Astiolo opened this issue Dec 24, 2021 · 4 comments
Labels
enhancement New feature or request

Comments

@Astiolo
Copy link

Astiolo commented Dec 24, 2021

Sometimes it's nice to have things building the latest version of something, while still being able to record the state it was in at the time.

I think this can be solved by including a git hash in the cpm-package-lock.cmake file in the build directory, so when archiving versions of the output, you can include that with it to know exactly what state the packages were in at the time it was built.

@TheLartians
Copy link
Member

Hey Astiolo, thanks for the issue! I agree that it makes a lot of sense to track the current commit hash in the package lock. This would also be a step towards a more modern package management approach (#99) and allow automatic updates etc in the future.

@TheLartians TheLartians added the enhancement New feature or request label Dec 30, 2021
@CraigHutchinson
Copy link
Contributor

💯 should be doing this for the cpm-update-package-lock if it is viable. Currently un-versioned targets are added as 'commented out' un-versioned dependencies which serves no useful purpose .. other than to simplify manually set the GIT_TAG to a SHA!

Also 'unversioned'... maybe should be non-versioned?

@CraigHutchinson
Copy link
Contributor

CraigHutchinson commented Sep 15, 2022

I have just found CPM_INCLUDE_ALL_IN_PACKAGE_LOCK which disabled the (unversioned) commenting.
😢 This doesn't resolve the GIT_TAG to a specific SHA reference (as per Git Submodule behavior would) and includes the Branch on which the package is updated from so doesn't help on its own!
🐞 ++ There may be a bug here in that CPM_ARGS_SOURCE_DIR is checked after this flag, will need to discern if this is worth of a new issue:

CPM.cmake/cmake/CPM.cmake

Lines 756 to 762 in 63d0de7

if((CPM_ARGS_VERSION AND NOT CPM_ARGS_SOURCE_DIR) OR CPM_INCLUDE_ALL_IN_PACKAGE_LOCK)
cpm_add_to_package_lock(${CPM_ARGS_NAME} "${ARGN}")
elseif(CPM_ARGS_SOURCE_DIR)
cpm_add_comment_to_package_lock(${CPM_ARGS_NAME} "local directory")
else()
cpm_add_comment_to_package_lock(${CPM_ARGS_NAME} "${ARGN}")
endif()

@TheLartians
Copy link
Member

There may be a bug here in that CPM_ARGS_SOURCE_DIR is checked after this flag, will need to discern if this is worth of a new issue

I think the original reasoning was that SOURCE_DIR would likely not be system-independent, which a package-lock optimally would be, so it was omitted here. However especially in the context of CPM_INCLUDE_ALL_IN_PACKAGE_LOCK I see how it would be still expected here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants