Add support for conditional dependencies via INCLUDE_IF keyword.
Still a work in progress. See #391 for more details.
To do (amongst other things probably):
- [ ] Write tests
- [ ] Update documentation
I'm against this. I'm pasting my comment from the linked discussion:
The proposed solutions would only work if all packages are listed in a central CMakeLists, and if this was the case, there would not be a point in having a package-lock. This central CMakeLists can play the same role.
But packages are listed in multiple CMakeLists files. My root can have code like:
if(BUILD_SERVER)
add_subdirectory(server)
endif()
if(BUILD_CLIENT)
add_subdirectory(client)
endif()
In such case the dependencies of the client won't even be mentioned, if only BUILD_SERVER is true and vice versa. And yes, as @itavero mentioned, different build flavors may require different versions of the same package, leading to an adverse package lock.
Thinking about all edge cases and different scenarios I'm even inclined to propose ditching package-lock altogether. Has anyone made a good use of it?
I think that package-lock should be at least rethought before proceeding with such changes
Yeah I definitely hadn't given it enough thought until now. Also sharing my comment from the discussion for completeness.
That's a really good point, package-lock definitely isn't compatible with conditional includes. Also to properly update the lock for nested dependencies we would need to somehow query any disabled packages as well making this feature much more difficult to implement than I initially anticipated.
I'm still in favour of keeping the feature, as having a package lock is crucial if we want to support automatic package updates (e.g. https://github.com/cpm-cmake/CPM.cmake/issues/318, https://github.com/cpm-cmake/CPM.cmake/issues/389), but we should make it clear that it doesn't work with conditional includes. As for INCLUDE_IF, it is still possible but would require running a separate temporary CMake process to resolve any nested dependencies when updating the package lock.
Going forward I do think the feature needs a hefty update and be used together with dynamic version tags as suggested in https://github.com/cpm-cmake/CPM.cmake/issues/318.