revert #3036, #2911, #1879, #1432: revert dashification of filenames#4478
revert #3036, #2911, #1879, #1432: revert dashification of filenames#4478PastaPastaPasta merged 5 commits intodashpay:developfrom
Conversation
kwvg
changed the title
|
This pull request has conflicts, please rebase. |
|
This pull request has conflicts, please rebase. |
|
This Pull Request may conflict if the Pull Requests below are merged first. #4649 |
kwvg
changed the title
|
This pull request has conflicts, please rebase. |
PastaPastaPasta
left a comment
PastaPastaPasta
left a comment
There was a problem hiding this comment.
utACK for squash merge assuming it passes CI
yeah... not sure I like it
this exact example is 1. not true and 2. it's a shared lib which is a bit more complex case, see dbc0474634 also, see few trivial fixes a9b9c2d209 |
|
pls rebase to include #4957 |
It's a shared library, so we should keep its name and API distinguishable from Bitcoin's and avoid pkgconfig confusion Co-authored-by: UdjinM6 <[email protected]>
PastaPastaPasta
left a comment
PastaPastaPasta
left a comment
There was a problem hiding this comment.
utACK for merging via merge commit
3 participants
Why?
As we're planning to support multiple build systems, remaining inline with their origin projects are a priority and surface-level filename rebranding serves as a quick and easy way to cause merge conflicts. We aim to remedy that. No logic or user-visible strings have been changed (outside of documentation)
Some filenames in the codebase will have the Dash branding, others don't. Only sources file that have a tendency to undergo change or are used by files that tend to undergo change were considered for the revert
Why not?
We now have an inconsistent naming scheme, despite being named
bitcoinconsensus, it will still output thelibdashconsensuslibrary