Gate install rules behind DX2_INSTALL option#44
Merged
Merged
Conversation
Only generate install rules when dx2 is the top-level project, so that parent projects consuming dx2 via add_subdirectory or FetchContent don't inherit them by default. The DX2_INSTALL option defaults to PROJECT_IS_TOP_LEVEL and can be overridden with -DDX2_INSTALL=ON when embedding consumers still want the install rules generated.
jbeilstenedmands
approved these changes
May 12, 2026
dimitrivlachos
added a commit
that referenced
this pull request
May 12, 2026
This reverts commit 28c7a33. The build failures that motivated the gate were caused by a stale dx2 installation in the active conda environment shadowing the in-tree headers and library, not by dx2's install rules themselves. With the stale artifacts removed from $CONDA_PREFIX, the unconditional install rules cause no issue when dx2 is consumed via add_subdirectory, and keeping them on is required so that downstream projects like the fast-feedback-service spotfinder install libdx2.so alongside their own binaries.
Collaborator
Author
|
@ndevenish made a good point refuting the reasoning of this, hence: |
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.
This PR makes dx2's install rules opt-in for embedded consumers, so that
projects pulling dx2 in via add_subdirectory or FetchContent no
longer inherit its install targets by default. Previously the install
rules ran unconditionally, which meant any parent project consuming dx2
would also install dx2's headers, library, and CMake package files into
the parent's install prefix - typically not what the parent wants.
Changes:
PROJECT_IS_TOP_LEVEL, so install rules are generated when dx2 is
built standalone but skipped when it is consumed as a subproject.
Consumers that do want the install rules in the embedded case can
re-enable them with -DDX2_INSTALL=ON.
install(EXPORT …), configure_package_config_file,
write_basic_package_version_file, and the DX2Config.cmake /
DX2ConfigVersion.cmake install block in if(DX2_INSTALL), leaving
the standalone install behaviour unchanged.
the module is available regardless of the install setting (it's
harmless to include and keeps the if() body focused on actual
install rules).
This allows downstream projects to embed dx2 directly via FetchContent /
add_subdirectory without polluting their own install tree, while
preserving the current standalone build-and-install workflow.