4 Commits

Author	SHA1	Message	Date
Jonathan Lebon	b640892f04	libdnf-sys: Drop C API, replace with cxx.rs bridge ... Right now, we're using libdnf APIs from Rust via hand-crafted `extern C` interfaces, which is extra dangerous because there is no signature checking that happens at compile-time. Until either we can automate libdnf bindings or use its C++ API directly via cxx.rs, let's do some basic wrapping in C++ ourselves and use libdnf through that API only instead. That gives us a lot more confidence and makes the libdnf API feel more natural to use in Rust.	2021-02-10 13:39:38 -05:00
Colin Walters	47c60eb6ce	libdnf: Various buildsys fixes ... WITH_SWDB: Removed in 99309fbe04 WITH_GIR Removed in e2f2862bed Also, most importantly: don't always reconfigure libdnf This is a questionable default for the cargo `cmake` crate. Building in Koji is failing I think due to timestamp issues causing cmake to run twice.	2021-02-04 17:57:33 -05:00
Colin Walters	588541c60d	Move libdnf build over to Cargo ... This is now further migration towards Cargo/Rust possible because we switched our main binary. We've had an internal `libdnf-sys` crate for a while, but now it can take over the build of the underlying library too (like many `-sys` crates support). This itself is just an incremental step towards migrating the main rpm-ostree build system to e.g. cmake too (or perhaps directly with the `cc` crate, not sure yet) and driving it via `cargo` too.	2021-02-04 10:59:20 -05:00
Colin Walters	2128f5784a	build-sys: Explicit workspace, move libdnf deps to crate ... First explicitly state that we're a workspace. AIUI this is actually implicit today via our use of a `path` dependency, but in the future we may have other sub-crates. So let's make it explicit now. Also move the libdnf dependencies directly to that sub-crate.	2021-02-04 10:59:20 -05:00