Use relative GNUInstallDirs install destinations#6
Merged
Conversation
…andalone Boost lookup or CI - install(): use relative GNUInstallDirs destinations so the superproject's packaging stages against its packaging prefix; absolute FULL_* paths baked the configure-time prefix into wire-sysio's dev packages, which the packaging verification correctly rejects - drop the stale standalone-only find_package(Boost 1.83 EXACT): appbase consumes the Boost targets already defined by wire-sysio's vcpkg toolchain (statically linked, currently Boost 1.89); a clear FATAL_ERROR guard remains for out-of-tree configures - remove the standalone build workflow: a distro-boost CI leg is neither representative of the real build nor satisfiable; appbase is compiled and tested by wire-sysio CI on every run
jglanz
force-pushed
the
fix/relative-install-destinations
branch
from
8f4de48 to
214de3c
Compare
appbase builds as a wire-sysio component: Boost targets come statically from the superproject's vcpkg toolchain (no standalone lookup), install rules use relative GNUInstallDirs destinations for the superproject's packaging, and there is no standalone CI workflow.
heifner
approved these changes
Jul 13, 2026
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
2 participants
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.
Absolute
CMAKE_INSTALL_FULL_*destinations bake the configure-time prefix into install paths. wire-sysio's packaging (Wire-Network/wire-sysio#511:/usr-prefixed deb+rpm and a portable tarball) stages installs against a packaging prefix chosen at cpack time, which requires relative destinations — with a pristine appbase,/usr/localpaths leak into thewire-sysio-devpackages, which the fedora install verification correctly rejects. Plaincmake --installbehavior is unchanged: relative destinations resolve againstCMAKE_INSTALL_PREFIXidentically (verified by wire-sysio's install-manifest regression gate).Also aligned with how appbase is actually built — as a wire-sysio component whose dependencies are assembled and statically linked through vcpkg (Boost 1.89, among others):
find_package(Boost 1.83 EXACT)is removed; the superproject defines theBoost::*targets before this directory is added, and a clearFATAL_ERRORguard remains for out-of-tree configuresCompanion to Wire-Network/wire-sysio#511; its
verify-packagesCI job stays red until this merges and the submodule gitlink bumps.