rewrite-install-paths: relocate CVC_DEPS_PREFIX too (fix assimp's absolute zlib export) - #413
Merged
Merged
Conversation
…export)
cvc_rewrite_install_paths (run automatically by cvc_cmake_build) rewrote
only absolute $CVC_INSTALL_DIR paths in installed .pc/.cmake files. But a
recipe's exported CMake target can also bake an absolute path to a
DEPENDENCY that lived under $CVC_DEPS_PREFIX at build time — the canonical
case is assimp, built with -DASSIMP_BUILD_ZLIB=OFF, whose CMake links
${ZLIB_LIBRARIES} (an absolute path from the classic FindZLIB module) and
exports THAT into assimpTargets.cmake instead of the relocatable ZLIB::ZLIB.
The path (/tmp/cvcpkg-builder/.../lib/libz.so) exists on no consumer, so any
downstream find_package(assimp CONFIG) + link assimp::assimp fails
everywhere — locally and in CI. (Worked around defensively in libcvc PR #158;
this fixes the root cause for every consumer.)
CMake relocates its OWN paths via ${_IMPORT_PREFIX}; the leak is external
dependency absolutes it does not touch. Extend the helper to rewrite
$CVC_DEPS_PREFIX paths to the same per-file ${CMAKE_CURRENT_LIST_DIR}/pc-file
anchor it already uses for $CVC_INSTALL_DIR — sound because cvcpkg's FLAT
install co-locates every dependency with the package at the consumer prefix.
It only fires where such a path literally appears (a no-op for exports that
are already clean), so it fixes the whole class without touching clean recipes.
Verified: a real 'cvcpkg build assimp' with this change produced an export
with ${CMAKE_CURRENT_LIST_DIR}/../../../lib/libz.so (no /tmp path), and a
find_package(assimp)+link consumer built cleanly with NO defensive rewrite.
New regression test tests/unit/test_rewrite_deps_prefix.py (fails without the
fix); existing rewrite tests still pass.
cvc_rewrite_install_paths is a POSIX build-time shell helper (sourced by cvc_cmake_build); the CI runs the Python unit suite on windows too, where bash/the helper do not apply. Guard the module with pytest.mark.skipif.
The +cvc.1 bundle baked an absolute build-sandbox zlib path into assimpTargets.cmake, so find_package(assimp)+link failed on every consumer. The shared rewrite-install-paths fix (this PR) makes the export relocatable; bump so populate-server publishes 6.0.5+cvc.2 carrying the corrected bundle (the catalog is immutable per version, so a same-revision republish would 409). libcvc's unpinned assimp dep picks up +cvc.2 automatically.
Dev-cluster recipe build — ⏳ submitted — still building on the cluster (see log); not blockingRecipes: build log |
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.
Problem
The published
assimpbundle'slib/cmake/assimp-6.0/assimpTargets.cmakehardcodes an absolute build-sandbox zlib path inINTERFACE_LINK_LIBRARIES:Root cause: the recipe builds assimp with
-DASSIMP_BUILD_ZLIB=OFF, so assimp's CMake links${ZLIB_LIBRARIES}— an absolute path from the classic FindZLIB module — and exports it instead of the relocatableZLIB::ZLIB. That path exists on no consumer, so any downstreamfind_package(assimp CONFIG)+target_link_libraries(... assimp::assimp)fails to link, locally and in CI. (Worked around defensively in libcvc #158; this fixes the root cause for every consumer.)Fix
cvc_rewrite_install_paths(auto-run bycvc_cmake_build) already relocates absolute$CVC_INSTALL_DIRpaths in installed.pc/.cmakefiles to a per-file${CMAKE_CURRENT_LIST_DIR}/${pcfiledir}anchor. It now does the same for$CVC_DEPS_PREFIXpaths — the external-dependency absolutes CMake does not relocate. Sound because cvcpkg's flat install co-locates every dependency with the package at the consumer prefix, so both prefixes map to the same anchor. It only fires where such a path literally appears, so it's a no-op for exports that are already clean — fixing the whole class, not just assimp.Verification
cvcpkg build assimpwith this change produced${CMAKE_CURRENT_LIST_DIR}/../../../lib/libz.so(no/tmppath, 0 leftover absolutes), and afind_package(assimp)+ link consumer built cleanly with no defensive rewrite.tests/unit/test_rewrite_deps_prefix.py(fails without the fix); existingtest_rewrite_readonly_files.pystill passes.After merge: rebuild + republish assimp so the catalog bundle carries the clean export; then libcvc's defensive rewrite becomes a harmless no-op.