build: Link `libbitcoinkernel` to `libbitcoin_util` #27285

This PR makes libbitcoinkernel reuse object files from libbitcoin_util instead of compiling them.

Also see doc/design/libraries.md

<!--e57a25ab6845829454e8d69fc972939a-->

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

<!--021abf342d371248e50ceaed478a90ca-->

Reviews

See the guideline for information on the review process.

If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.

This PR makes libbitcoinkernel reuse object files from libbitcoin_util instead of compiling them.

Why

This PR makes libbitcoinkernel reuse object files from libbitcoin_util instead of compiling them.

Why

Isn't libbitcoin_util supposed to be a reusable build artifact?

And in master branch libbitcoinkernel_la_SOURCES and libbitcoin_util_a_SOURCES have almost the same source file lists.

NACK. This is pretty literally the opposite of what we want to be doing with the kernel.

And in master branch libbitcoinkernel_la_SOURCES and libbitcoin_util_a_SOURCES have almost the same source file lists.

The whole point of having these files enumerated, is so that we know what is currently in the kernel, and can continue to (easily) prune deps, while refactoring. Hiding this away into libbitcoin_util only makes this harder/impossible to do, and you're just removing the current, explicit listing, of what makes up the kernel.

Concept NACK

Isn't libbitcoin_util supposed to be a reusable build artifact?

Maybe, but linking in the entirety of the util library is not what the kernel project is currently trying to achieve. The goal is to prune as many files as possible out of the library. This also stated in stage 1 step 2 of the original kernel issue: #24303 . Once stage 2 is reached, there may be a discussion again of a shared build artifact containing the intersection of files between the kernel and another library. Since there is no telling yet what this might look like, I don't think it's productive to discuss now or in the nearer future.

Agree with the NACKs here. It would be nice if we could share the objs to reduce compilation time, but there are good reasons to keep things separate.

But to add another practical problem, eventually libbitcoinkernel will need to be built with a -DLIBBITCOINKERNEL_SHARED or so once it gains an API. That would mean that objects are no-longer identical to (or shareable with) our internal libs.