feat(build): replace unwraps by expects with useful messages in build.rs

[jaoleal]

libbitcoinkernel-sys/build.rs` was executing a cmake binary from the environment and doing some manual flag and path configuration. The presented changes delegate the same job to the cmake crate which should handle dependencies accross environments.

But im not certain if the choice of not using this crate is on purpose.

fix: #135

[jaoleal]

I got a problem while trying to build on windows, still working on that.

But feedback on overall approach does apply, specially regarding the cmake crate.

[jaoleal]

Okay, apparently the problem was due flag conflict and is resolved in b061f0a

CI is passing now.

[alexanderwiederin]

Thanks @jaoleal!

I think the raw cmake approach is more explicit and already works well. To fix #135, we can find a simpler solution. Could you give an example of an environment where the old approach failed?

[yancyribbens]

To fix #135, we can find a simpler solution.To fix #135, we can find a simpler solution.

I agree, maybe if you could split this out into separate commits it would be more clear. As it stands, if you are only address #135, this seems very complex.

[sedited]

I agree with @alexanderwiederin and @yancyribbens . I think we should strive to have as few build and runtime dependencies as possible. I think there should be an easier way to surface a nicer error to address #135.

[jaoleal]

Ok, so:

1. 18d643a Concisely addresses Throw expect() message if deps are not found #135.
2. f8d36d Delegates command handling to the cmake crate.

My rationale for addressing #135 with the cmake crate is thats the ""oficial"" way to do it, found it while searching how should i deal with Build Scripts, since it already have some more granular error handling and error messages i thought for it to be a better fit to address #135.

The cmake is well-maintained and its only dependency is cc, which is already added in libbitcoinkernel-sys/Cargo.toml. On my slow laptop (i3-13gen + 8gbram) the build time were negligible. And this approach matches the same approach that was taken when using the cc crate.

By the other side, I understand if you guys still prefer the old approach. I can drop f8d36d and we can follow with 18d643a

[jaoleal]

Applied requested changes.

@yancyribbens please take a look if the current approach on a753eed suits. I tried to make the error handling more usefull than a single unwrap but not extending much.

Now theres difference between when finding cmake and executing it.

[jaoleal]

Done! @yancyribbens

[jaoleal]

Renaming the PR to match the current approach

[jaoleal]

@yancyribbens done in 4956e1b.

[jaoleal]

corrected capitalization on 26cdab4

[yancyribbens]

LGTM - thanks for improving the messaging.