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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
This way we're sure it will build in e.g. Koji. Right now
it's annoying to test that locally; one needs to explicitly
create a no-network container to do so strictly. But
cargo has a convenient `--offline` flag, and nothing else
in our build stack should touch the network.
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.
In the previous buildsytem rework we disabled the unit tests because
of linking problems. Now I realized that a simple solution is
to continue to build one big object, just make it an internal
static library and have a tiny "stub main" that delegates to an entrypoint.
That's basically what the C unit tests are - an alternative `main()`
with some extra code.
There won't be any support for writing to the bdb backend in f34, so
e.g. pkglayering won't work (and obviously even composes wouldn't work
once the buildroot moves to f34).
Instead of requiring the whole world to add an `rpmdb` key in their
manifests, let's just add a compile flag for it, and tweak the spec file
to use this flag on f34.
This completes the task of unifying the build of all of our C/C++
into a single unit, which avoids code duplication and will allow
us to more easily use LTO in the future.
A long time ago we de-duplicated the daemon and binary
into a single executable, but left the daemon code
building as an internal static library.
Let's take the next step and compile the sources directly as part
of the executable build. For example, we can then de-duplicate
the `CFLAGS/CXXFLAGS`. And in the future this will help us
turn on LTO.
This is a potential path to fix
https://github.com/coreos/rpm-ostree/issues/2391
Basically our shared library and executable duplicate too much
code (particularly Rust). Since most of the shlib APIs aren't
performance sensitive, let's have them fork off the binary
via a hidden CLI entrypoint and parse the output.
First, we now need the `vendor/` directory at the toplevel because
that's where `Cargo.toml` is.
Now this triggers another bug introduced in the build system
with how we're handling the `rpmostree-rust.h` header.
We ended up vendoring a pre-generated one in the tarball
mainly because RHEL doesn't include cbindgen.
Now probably in the future I'd like to fix that.
But let's clean this up - the tarball generation process copies
the file into `rpmostree-rust-prebuilt.h`, and build machinery
detects that and entirely skips looking for or trying to build
our internal cbindgen.
I think we should have done this as soon as it was clear that
Rust was sticking and not just an optional thing.
Reasons to make this change now:
- More clear that Rust is going to be the majority of code in the future
- `cargo build` and `cargo test` in a fresh git clone Just Work
- Paves the way for using `cargo` to build C/C++ instead of Automake
I still think we should do this at some point, but
the experiment with using `GKeyfile` for configuration
is IMO a failure and the variety of data formats
(treefile JSON vs YAML vs origin keyfiles vs container keyfiles)
causes a lot of confusion.
Prep for https://github.com/coreos/rpm-ostree/issues/2326
