build: Refactor visibility logic and add override#1696
Merged
real-or-random merged 3 commits intobitcoin-core:masterfrom Jul 21, 2025
Merged
build: Refactor visibility logic and add override#1696real-or-random merged 3 commits intobitcoin-core:masterfrom
real-or-random merged 3 commits intobitcoin-core:masterfrom
Conversation
Loading
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
6 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 is less invasive than #1695. The latter might be the right thing in a new library (and then we'd probably not support autotools in the first place), but any semantic change to this code has the potential to create news bug, or at least breakages for downstream users.
This is different from #1677 in that it does not set
hiddenexplicitly. I agree with the comment in #1677 that settinghiddenviolates the principle of least surprise.So this similar in spirit to #1674. So I wonder if this should also include
3eef736. I'd say no,
fvisibilityshould then set by the user. But can you, in CMake, setCMAKE_C_VISIBILITY_PRESETfrom a parent project?