IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
We need to do the same `cmp` dance for the generated `.cxx` file
as for the source, because `make` only works on timestamps.
Currently every time one edits the rust code and types `make`
we end up re-building that object, which also forces a re-link
of the `librpmostreeinternals.la` library.
We have fully transitioned to cxx-rs! This drops a lot of now
dead code; only one binding system to think about generating
source code. For example, a notable advantage of cxx-rs
is it doesn't scan the whole source code, so running `make`
doesn't spew errors from cbindgen not understanding bits.
We've had a problem for a long time that e.g. `rpmostree-rust.h`
didn't have dependencies on the relevant Rust sources, so changing
it required `rm -f rpmostree-rust && make` which is very confusing.
Improve things here for both it and cxx.rs so that we use
content-based change detection (this is a default in more modern
build systems). This way e.g. `touch Cargo.toml && make` won't
implicitly result in rebuilding all of the C/C++ side.
cxx.rs (aka cxxbridge) and cbindgen are
both generating source code. Since the last release
we've introduced the former, and we need to ensure
that the generated cxx.rs source ends up in release tarballs
the same way as the cbindgen code.
Rationalize and clean up the binding infrastructure.
Drop support for the vendored cbindgen which we
weren't actually using:
Closes: https://github.com/coreos/rpm-ostree/issues/2392
Move the cxx-rs and cbindgen bits into the same place,
and update our CoreOS CI build to use a separate `Makefile.bindings`
that just generates the code, so our CI still "works like"
a main Koji RPM build.
