Cory Fields

Concept ACK-ish, but only with 100% feature parity. This is the kind of work that's easy enough to get 90% of the way there, but the remaining 10% will almost...

@ryanofsky I didn't mean to imply that there's anything that wouldn't be possible with CMake, just that there's a _lot_ to get done other than vanilla builds. A long list...

> Just to explain my concept ACK a little bit: I don't think CMake build needs to add much of a maintenance burden and don't think it needs to have...

@ryanofsky Please re-read my comments and please don't twist my words. Nowhere to I advocate for autotools. I hate it. it's dated and awful. In each comment I've advocated FOR...

@ryanofsky as for partial/incremental support of CMake, I suppose my hesitation (which I should've made more clear) is that neither a (partial) build-system switch or a long-term feature merge happen...

@hebasto Yes thanks, that's a huge help! One other helpful set of features to add would be convenience targets used by release processes/ci/etc. There are lots, but `make deploy` and...

> Sorry, it's a really bad thing to misrepresent someone's position and I was not trying to do that. I wasn't trying to say you personally prefer autotools, just that,...

> (2) allow each build system to have different features for other development and don't insist on parity More specifically, I don't think that a flag-day switch-over would be the...

> As the `crc32c` project modifies the `CMAKE_CXX_FLAGS` variable directly, it must be fixed within the project (a bad CMake practice case -- global compiler flags instead of binding them...

This is amazing! > Using glibc for static builds, would be less of a leap compared to switching to musl libc (POC in https://github.com/bitcoin/bitcoin/pull/23203). Hard agree. Static musl builds would...