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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Prep for the [fedora-integration PR](https://github.com/coreos/rpm-ostree/pull/2420).
This also generalizes the "fetch URL to tempfile" code into
supporting multiple at once - it's much more efficient to do
it that way because we can reuse a TCP connection to servers,
parsed certificates etc.
Now that the whole core codebase is "compile in C++ mode",
remove the ifdef and move the C++-specific `#include <>`s
up so it's more obviously supported to add new
C++ code (if necessary).
We previously severed the dependency between the shared library
and our internal code, but the library still included internal
headers even though they weren't used.
This broke my attempt to natively use C++ in some headers.
Drop the unused headers and clean up the `#include`s.
(I'm going to start calling it `live-apply` instead of "livefs")
On one hand, this drops the unsafe bindgen glue. On the other
hand it demonstrates a notable current ergonomic shortfall of
cxx-rs in that it doesn't support `Option<T>`, so we represent
optional strings by converting them to empty strings.
(Relatedly I discovered in C++ there is `std::optional<>` but it's in C++17.
I assume we can depend on that but let's for now match libdnf's
usage of `-std=c++14` because we know that works everywhere)
cxx-rs has support for bridging types, but it's more awkward
for us because those types are defined in other crates, so
we need to do a newtype dance. Further cxx-rs doesn't currently
support automatically generating wrappers, so add a custom
`gobj_wrap()` for now.
I started writing a comment about why we run autotools twice,
then decided that was *much* uglier than extracting the binding
rules to a separate `Makefile`. But I forgot to go back
and remove the first part, so do that now and fix up the comment.
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.
Rust has a nice crate for doing perfect hashing. Move that
code into Rust and drop the dependency on `gperf`. This also
helps move away from Autotools.
AFAICT, we just need `cxxbridge` to be in the `PATH` of the building
user. Let's avoid targeting privileged paths so devs can just run this
script directly without `sudo`.
The way gresources work using a constructor function started
failing when I was refactoring the build system, and I couldn't
figure it out. It's just easier to use Rust for this which
has nice toolchain-integrated functionality for this.
This is much better than bindgen because it's fully safe. It's
much more ergonomic too:
- Invoke Rust methods-on-structs just like C++ methods-on-structs
- Rust `Result<>` is translated automatically to exceptions
See https://cxx.rs/context.html for more.
We need to cleanly split off "test dependencies" that we
install inside the cosa pod from builds (where we won't
have `cargo`) from the build time where we use the cosa
buildroot image.
Prep for using https://cxx.rs
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.
The cool thing about this is it emphasizes how "integrated" apply-live
is versus the uncontrolled `rpm-ostree usroverlay`. We're still
tracking the state of things reliably and can print it.
We set it to the same value in both cases. There's no reason
to require it at build time anyways.
Part of thinning out the Autotools side in prep for using Cargo.
We aren't going to be shipping major new versions to RHEL7
ever again, so drop this compat definition.
Drop this as part of thinning out our Autotools build system
in preparation for moving to `build.rs`.
This was only needed for RHEL7; RHEL8 and above ships bwrap with
the OS.
Drop this as part of thinning out our Autotools build system
in preparation for moving to `build.rs`.
