< bitcoin-git>
[bitcoin] klementtan opened pull request #22282: refactor: CheckFinalTx pass by reference instead of ptr (master...CheckFinalTx_ptr_to_ref) https://github.com/bitcoin/bitcoin/pull/22282
< glozow>
ariard: thanks, I'll take a look.
< bitcoin-git>
[bitcoin] dgoncharov opened pull request #22283: build: Replace $(AT) with .SILENCE. (master...replace_AT_with_dotsilence) https://github.com/bitcoin/bitcoin/pull/22283
< bitcoin-git>
[bitcoin] jonatack opened pull request #22284: p2p, refactor: performance improvements to ProtectEvictionCandidatesByRatio() (master...ProtectEvictionCandidatesByRatio-perf-enhancements) https://github.com/bitcoin/bitcoin/pull/22284
< kittywhiskers>
noticed the addition of crc32c to the subtree, been a bit since i've seen recent developments
< kittywhiskers>
how is a library decided to be committed to the source tree or added as depends pkg?
< kittywhiskers>
i get why submodules are not ideal, github doesn't generate source archives with submodule trees but i'm still curious as to how those decisions are made
< sipa>
we use git subtrees
< bitcoin-git>
[bitcoin] whitslack opened pull request #22285: contrib/init: (OpenRC) use -startupnotify to wait for startup completion (master...openrc-startupnotify) https://github.com/bitcoin/bitcoin/pull/22285
< kittywhiskers>
never heard of it till now, a light reading shows that it creates a bit of overhead but that makes sense for a project like core
< sipa>
and the decision to use a subtree vs external dependency depends on (a) how tightly consensus code needs it (we don't want consensus-relevant things to just pick whatever version is available on your system and (b) how readily available it is as a package
< sipa>
crc32 is a dependency of leveldb, en leveldb is used for the UTXO set, so we want control over the version used
< sipa>
libqrencode for example is just used by the GUI, and easily available
< sipa>
so that isn't a subtree
< kittywhiskers>
makes sense then, just figured that maybe core could fork the repo, issue a core-specific release and link the URL to that archive as a depends pkg
< kittywhiskers>
best of both worlds, i'm asking as i'm interested in implementing cmake secp support
< kittywhiskers>
just dipping my toes in the pond to see if that's welcome
< kittywhiskers>
i thought that repo was abandoned for some reason, huh
< sipa>
hmm, maybe we use upstream now
< sipa>
i'm not entirely sure!
< kittywhiskers>
yeah, the basic dev docs don't mention subtrees anywhere so this is news to me
< kittywhiskers>
i've usually just went along with it, just now that i think about it, figured i'd pop in and ask instead of filing a github issue about it :P
< sipa>
oh they are documented somewhere
< sipa>
in doc/developer-notes.md
< sipa>
regarding libsecp256k1... #secp256k1 is probably a better place
< sipa>
but in short, there is a (rather slow) ongoing effort of reducing the burden of the build system
< sipa>
and we're pretty close to just being able to build by invoking a C compiler in many settings
< kittywhiskers>
i did some preliminary work on getting bitcoin core to build using cmake, like how monero does it
< kittywhiskers>
that then got me into univalue, secp256k1 and then so on and so forth, luckily leveldb already uses cmake
< sipa>
well i don't think bitcoib core will switch to cmake
< kittywhiskers>
i don't mean as a replacement, the current system seems more than efficient
< kittywhiskers>
merely in parallel
< sipa>
ok
< kittywhiskers>
though i do think long term with process separation, cmake does seem like a good option
< kittywhiskers>
also, turns out the first references to subtrees were five years ago, i should really read more than build-generic.md :P
< kittywhiskers>
would a PR that tries to unify all instances of the word "Bitcoin" be welcome?
< sipa>
what do you mean?
< kittywhiskers>
similar to the PR that unified all uses of BTC across the codebase, now that with the word Bitcoin itself
< kittywhiskers>
i think the idea of having a refactor where all references to bitcoin in filenames are replaced with core and all mentions of Bitcoin in the source lead back to a static variable is worth considering
< sipa>
i'd need to see the PR to know what you mean... generally PRs that touch code in lots of different places are annoying
< kittywhiskers>
yeah, it would break tons of existing PRs so it'll have to be done in small bits
< sipa>
that doesn't sound worth doing... just high cost low benefit
< kittywhiskers>
afaik there's already precedent with Cryptonote doing something similar, you name the asset something and keep the name separate from the software that implement's the underlying protocol, marking a distinction between the two
< kittywhiskers>
yeah, it would be a pain to manoeuvre but figured if done in an organised fashion, it would be viable
< kittywhiskers>
starting with class names, filenames and then slowly changing out references across the interface to the static value, in a similar way to something like the CAmount refactor or the ticker refactor
< sipa>
oh you mean in the source code, not something observable?
< sipa>
i think that's very unlikely to attract reviewer attention
< kittywhiskers>
i was hoping to start with non-observable portions and then work up my way to the UI
< kittywhiskers>
my interest in this stems from the core's forks resorting to a very liberal use of search-and-replace that makes porting changes to-and-from projects a real inconvenience, even if they're fundamentally based on the same version
< kittywhiskers>
i think even litecoin, which is relatively conservative in their use of SaR deals with merge conflicts from inlining
< sipa>
no offense, but i couldn't care less about that
< kittywhiskers>
eh, fair enough
< kittywhiskers>
no offence taken
< kittywhiskers>
still think it's a neat refactoring idea, figured i'd ask as there already seemed to be precedent
< kittywhiskers>
i don't mind having to rebase the repo again and again, i planned on doing it as a series of scripted-diffs anyways, just wanted to see the response before i sit down and get to it