CMakeLists: drop EXACT from find_package(Lua X.Y EXACT REQUIRED) - #1755
Open
ShuangLiu1992 wants to merge 1 commit into
Open
CMakeLists: drop EXACT from find_package(Lua X.Y EXACT REQUIRED)#1755ShuangLiu1992 wants to merge 1 commit into
ShuangLiu1992 wants to merge 1 commit into
Conversation
Each of the per-version branches (5.1, 5.2, 5.3, 5.4) calls find_package
with the EXACT keyword. EXACT requires the FOUND version to match the
requested version exactly, which is overly restrictive for two
real-world configurations:
- CMake's bundled FindLua reads `lua.h` and reports a 3-component
version (e.g. "5.4.7"). EXACT 5.4 requires the FOUND major.minor
components to match; that works on most systems, but pinning
`SOL2_LUA_VERSION=5.4.4` (sol2's default) causes the EXACT check
to silently accept any 5.4.x — which is the same behavior as
dropping EXACT — while making 5.4.7 → match harder if a stricter
version comparison is applied.
- When Lua is provided by a CMake-config package (e.g. Conan, vcpkg)
rather than CMake's bundled FindLua, the package's
`LuaConfigVersion.cmake` controls compat. EXACT requires its
`PACKAGE_VERSION_EXACT` flag to be set, which providers don't
usually do for major.minor-style queries. The non-EXACT call
simply requires `PACKAGE_VERSION_COMPATIBLE`, which is the
sensible default.
Removing EXACT keeps the major.minor version constraint via the
trailing `X.Y` argument — sol2 still binds to the requested Lua major
release. The patch-version exactness was effectively a CMake quirk,
not a correctness requirement: sol2's bindings work for any 5.4.x.
This unblocks providing Lua via CMake-config packages (any Conan or
vcpkg setup), which previously failed at the EXACT check.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Motivation
Each of the per-version branches (5.1, 5.2, 5.3, 5.4) currently calls
find_package(Lua X.Y EXACT REQUIRED). TheEXACTkeyword requires theFOUND version to match the requested version exactly, which is overly
restrictive — and silently broken when Lua is supplied by a CMake-config
package (Conan, vcpkg) rather than CMake's bundled FindLua module.
Real-world failures
Config-mode providers: a package's
LuaConfigVersion.cmakereportsPACKAGE_VERSION_COMPATIBLE=TRUEfor major-version-compatible queriesbut only sets
PACKAGE_VERSION_EXACT=TRUEwhen the FOUND versionstring equals the requested string exactly. For
find_package(Lua 5.4 EXACT)this needs
PACKAGE_VERSION = "5.4"exactly — providers usuallyreport
"5.4.7"(or a SHA / build identifier), so the EXACT matchfails and find_package silently falls through.
Module mode: CMake's bundled FindLua reads
lua.hand reports a3-component version like
"5.4.7". EXACT 5.4 still matches viacomponent-prefix semantics, so this path mostly works — but the
asymmetry between Module and Config mode is fragile.
Change
Drop the
EXACTkeyword from all four per-version branches. Thefind_package(Lua X.Y)call still constrains the Lua major.minorrelease to what the user asked for via
SOL2_LUA_VERSION(default5.4.4) — sol2 still binds to a specific Lua major. The patch-version
exactness was effectively a CMake quirk, not a correctness requirement:
sol2's bindings work cleanly against any 5.4.x.
Notes
find_package(Lua 5.4)accepts any 5.4.x, which is exactly the same set of Lua releases sol2
supports per-major (no patch-version-specific binding code).
lualib,LUA_LIBRARIES,LUA_INCLUDE_DIRall behave the same.Lua is provided as
lua/<sha>; this PR makes that wiring workupstream too.