`write_basic_package_version_file` and version range

From reading the templates used by write_basic_package_version_file it seems that the parent project has the ultimate say of how the find_package works, e.g. if SameMajorVersion is used, passing a range like 2.0...4.0 will always fail because only version ranges with the same major are supported.

But then the question is, if the consuming project has a special handling for those ranges so that all of them are supported, how should we design around the packaged project’s restrictions? My only guess is to design a Find<Package>.cmake wrapper where the version range is processed, setting the final <Package>_FOUND variable.

Edit: I’ve noticed a flaw with the Find<Package>.cmake approach. Let’s assume we are consuming via

FetchContent_Declare(ProjectA
		GIT_REPOSITORY https://github.com/user/project-a
		GIT_TAG v2.3.0
		FIND_PACKAGE_ARGS MODULE
		)

With a FindProjectA.cmake file like:

find_package(ProjectA CONFIG)
if (ProjectA_VERSION VERSION_LESS 2)
  set(ProjectA_FOUND FALSE)
elseif (ProjectA_VERISON VERSION_GREATER 3)
  message(WARNING "Support for ProjectA ${ProjectA_VERISON} is experimental. Please report to ...")
endif ()

The issue is that within the FindProjectA.cmake, the targets were already defined by find_package(CONFIG), so when it goes through FetchContent path as the fallback, the target names can potentially clash.

1 Like

I don’t know that the templates ever considered version ranges; I suspect that it is older than range support at all (@brad.king?).

As for conflicting targets, yes, that seems like a problem. However, I think it is more that dependency management needs to be a bit more uniform within a single CMake project rather than “handle all possible conflicts”. @craig.scott?