keremet/rpm-ostree
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
5060cdf7fc
rpm-ostree/Makefile-rpm-ostree.am

158 lines
6.2 KiB
Plaintext
Raw Normal View History

Initial import from pkgsys-ostree
2013-12-22 04:41:30 +04:00
# Copyright (C) 2013 Colin Walters <walters@verbum.org>
#
# This library is free software; you can redistribute it and/or
# modify it under the terms of the GNU Lesser General Public
# License as published by the Free Software Foundation; either
# version 2 of the License, or (at your option) any later version.
#
# This library is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# Lesser General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public
# License along with this library; if not, write to the
# Free Software Foundation, Inc., 59 Temple Place - Suite 330,
# Boston, MA 02111-1307, USA.
buildsys: Make one big rpmostreeinternals.la, enable unit tests again 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.
2020-12-21 17:15:28 +03:00
noinst_LTLIBRARIES += librpmostreeinternals.la
librpmostreeinternals_la_SOURCES = \
src/app/libmain.cxx \
build: Split up src into `app/` and `libpriv/` We currently have an internal-only library, but the sources for it are in the same dir as the app. For future work on a public shared library, we'll need a clearer source structure. Start by just renaming the app files into `src/app/`, and the internal private library into `src/libpriv/`, with the appropriate `Makefile.am` changes. Closes: https://github.com/projectatomic/rpm-ostree/pull/123
2015-04-07 03:18:50 +03:00
src/app/rpmostree-builtins.h \
src/app/rpmostree-db-builtins.h \
src/app/rpmostree-compose-builtins.h \
Port rpmostree-builtin-upgrade to C++ Prep for using https://cxx.rs/
2020-12-21 19:08:51 +03:00
src/app/rpmostree-builtin-upgrade.cxx \
Port rpmostree-builtin-rollback to C++ Prep for using https://cxx.rs/
2020-12-21 19:08:51 +03:00
src/app/rpmostree-builtin-rollback.cxx \
Port rpmostree-builtin-deploy to C++ Prep for using https://cxx.rs/
2020-12-21 19:08:51 +03:00
src/app/rpmostree-builtin-deploy.cxx \
Port rpmostree-builtin-reload to C++ Prep for using https://cxx.rs/
2020-12-21 19:08:51 +03:00
src/app/rpmostree-builtin-reload.cxx \
Port rpmostree-builtin-rebase to C++ Prep for using https://cxx.rs/
2020-12-21 19:08:51 +03:00
src/app/rpmostree-builtin-rebase.cxx \
Port rpmostree-builtin-cancel to C++ Prep for using https://cxx.rs/
2020-12-21 19:08:51 +03:00
src/app/rpmostree-builtin-cancel.cxx \
Port rpmostree-builtin-cleanup to C++ Prep for using https://cxx.rs/
2020-12-21 19:08:51 +03:00
src/app/rpmostree-builtin-cleanup.cxx \
countme: Add DNF Count Me support Add support for the DNF Count Me feature [1,2,3] as a standalone rpm-ostree subcommand called weekly via a systemd timer. [1] https://fedoraproject.org/wiki/Changes/DNF_Better_Counting [2] https://dnf.readthedocs.io/en/latest/conf_ref.html?highlight=countme#options-for-both-main-and-repo [3] https://github.com/rpm-software-management/ci-dnf-stack/blob/master/dnf-behave-tests/features/countme.feature
2020-10-13 18:46:00 +03:00
src/app/rpmostree-builtin-cliwrap.cxx \
Port rpmostree-builtin-initramfs to C++ Prep for using https://cxx.rs/
2020-12-21 19:08:51 +03:00
src/app/rpmostree-builtin-initramfs.cxx \
Port rpmostree-builtin-initramfs-etc to C++ Prep for using https://cxx.rs/
2020-12-21 19:08:51 +03:00
src/app/rpmostree-builtin-initramfs-etc.cxx \
Port rpmostree-builtin-livefs to C++ Prep for using https://cxx.rs/
2020-12-21 19:08:51 +03:00
src/app/rpmostree-builtin-livefs.cxx \
Port rpmostree-builtin-usroverlay to C++ Prep for using https://cxx.rs/
2020-12-21 19:08:51 +03:00
src/app/rpmostree-builtin-usroverlay.cxx \
Port rpmostree-builtin-override to C++ Prep for using https://cxx.rs/
2020-12-21 19:08:51 +03:00
src/app/rpmostree-builtin-override.cxx \
Port rpmostree-builtin-refresh-md to C++ Prep for using https://cxx.rs/
2020-12-21 19:08:51 +03:00
src/app/rpmostree-builtin-refresh-md.cxx \
Port rpmostree-builtin-reset to C++ Prep for using https://cxx.rs/
2020-12-21 19:08:51 +03:00
src/app/rpmostree-builtin-reset.cxx \
Port rpmostree-pkg-builtins to C++ Prep for using https://cxx.rs/
2020-12-21 19:08:51 +03:00
src/app/rpmostree-pkg-builtins.cxx \
Port rpmostree-builtin-status to C++ Prep for using https://cxx.rs/
2020-12-21 19:08:51 +03:00
src/app/rpmostree-builtin-status.cxx \
Port rpmostree-builtin-ex to C++ Prep for using https://cxx.rs/
2020-12-21 19:08:51 +03:00
src/app/rpmostree-builtin-ex.cxx \
Port rpmostree-builtin-testutils to C++ Prep for using https://cxx.rs/
2020-12-21 19:08:51 +03:00
src/app/rpmostree-builtin-testutils.cxx \
Port rpmostree-builtin-shlib-backend to C++ Prep for using https://cxx.rs/
2020-12-21 19:08:51 +03:00
src/app/rpmostree-builtin-shlib-backend.cxx \
Port rpmostree-builtin-db to C++ Prep for using https://cxx.rs/
2020-12-21 19:08:51 +03:00
src/app/rpmostree-builtin-db.cxx \
Port rpmostree-builtin-start-daemon to C++ Prep for using https://cxx.rs/
2020-12-21 19:08:51 +03:00
src/app/rpmostree-builtin-start-daemon.cxx \
Port rpmostree-builtin-finalize-deployment to C++ Prep for using https://cxx.rs/
2020-12-21 19:08:51 +03:00
src/app/rpmostree-builtin-finalize-deployment.cxx \
Port rpmostree-db-builtin-dif to C++ Prep for using https://cxx.rs/
2020-12-21 19:08:51 +03:00
src/app/rpmostree-db-builtin-diff.cxx \
Port rpmostree-db-builtin-list to C++ Prep for using https://cxx.rs/
2020-12-21 19:08:51 +03:00
src/app/rpmostree-db-builtin-list.cxx \
Port rpmostree-db-builtin-version to C++ Prep for using https://cxx.rs/
2020-12-21 19:08:51 +03:00
src/app/rpmostree-db-builtin-version.cxx \
app: Port dbus-helpers to C++ Prep for using https://cxx.rs/
2020-12-06 22:38:13 +03:00
src/app/rpmostree-dbus-helpers.cxx \
daemon: Make parts of cli use the daemon
2015-06-13 03:19:16 +03:00
src/app/rpmostree-dbus-helpers.h \
app: add experimental support for pkg removals This is one more step towards making rpm-ostree more powerful in its quest to be the ultimate *hybrid* image/package system. Package layering allows us to add packages on top of the base package set received from the content provider. However, we're not able to remove or replace packages in the base set itself. This patch introduces a new `override` command, which is for now nested under the experimental `ex` command. The `override` command will allow users to modify the base package set itself. The first implemented subcommands are `remove` and `reset`. A stub has been provided for the more useful `replace` subcommand, though much of the needed logic for that operation are implemented in this patch as part of the `remove` subcommand. Part of: https://github.com/projectatomic/rpm-ostree/issues/485 Closes: #797 Approved by: cgwalters
2017-06-05 19:37:56 +03:00
src/app/rpmostree-override-builtins.h \
Port rpmostree-override-builtins to C++ Prep for using https://cxx.rs/
2020-12-21 19:08:51 +03:00
src/app/rpmostree-override-builtins.cxx \
Port rpmostree-libbuiltin to C++ Prep for using https://cxx.rs/
2020-12-19 21:14:18 +03:00
src/app/rpmostree-libbuiltin.cxx \
Move diff printing code into client This is a step forward to deduplicating; the client tooling now calls into the public API for diffs, rather than using the older internal function. Note: this patch also links the client against the public library.
2015-04-19 16:36:53 +03:00
src/app/rpmostree-libbuiltin.h \
Port rpmostree-polkit-agent to C++ Prep for using https://cxx.rs/
2020-12-21 19:08:51 +03:00
src/app/rpmostree-polkit-agent.cxx \
app: spawn polkit authentication agent Spawn pkttyagent when trying to call a method that may require authentication to give users a chance to provide auth right from the terminal. Since we're now relying on polkit for authorizing most of the OS interface methods, let's drop the root check on those. Closes: #894 Approved by: cgwalters
2017-07-25 19:59:56 +03:00
src/app/rpmostree-polkit-agent.h \
Port rpmostree-builtin-kargs to C++ Prep for using https://cxx.rs/
2020-12-21 19:08:51 +03:00
src/app/rpmostree-builtin-kargs.cxx \
Convert some code to compile in C++ mode This is part of investigating using https://cxx.rs/ In order to make this really work, we need to convert some of our C code to C++ so we can include cxx.rs-generated code. This starts by converting just two files as a starting point. I did the minimal porting; I didn't try to actually rewrite them to resemble modern C++, just "C in C++ mode".
2020-11-22 22:55:06 +03:00
src/app/rpmostree-compose-builtin-tree.cxx \
Port rpmostree-composeutil to C++ Prep for using https://cxx.rs
2020-12-19 00:42:28 +03:00
src/app/rpmostree-composeutil.cxx \
compose: Split off composeutil.[ch] Prep for adding a new toplevel rojig command. It's also just cleaner to avoid cluttering up the main compose logic with distractions like the `_legacy_prep_dev()` bits. Closes: #1564 Approved by: jlebon
2018-09-19 16:48:04 +03:00
src/app/rpmostree-composeutil.h \
Port rpmostree-builtin-compose to C++ Prep for using https://cxx.rs/
2020-12-21 19:08:51 +03:00
src/app/rpmostree-builtin-compose.cxx \
buildsys: Compile daemon code directly with binary 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.
2020-12-17 01:17:49 +03:00
$(librpmostreed_sources) \
buildsys: Unify build of binary and internal shared library 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.
2020-12-17 01:04:40 +03:00
$(librpmostreepriv_sources) \
Unify rpm-ostree into one binary And start making an internal library.
2014-01-29 23:37:44 +04:00
$(NULL)
Add --disable-compose-tooling build option Some downstreams want the ability to separate the compose tooling from the client, for e.g. support reasons. This approach supports generating a tarball without the source for the compose command, and requires specifying a config option to disable it.
2014-09-17 05:45:30 +04:00
Add --enable-rojig, disable by default We're seeing some CI failures that I think are a bug in rojig. In the bigger picture...we never actually started using this, and I think longer term shipping os updates via containers probably makes more sense. I put a *lot* of effort into this code and it's pretty cool so it's hard to just delete it. And *maybe* someone out there is using it (but I doubt it). So rather than just deleting it entirely let's make it a build-time option. I verified that it builds at least.
2020-10-22 20:33:45 +03:00
if BUILDOPT_ROJIG
buildsys: Make one big rpmostreeinternals.la, enable unit tests again 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.
2020-12-21 17:15:28 +03:00
librpmostreeinternals_la_SOURCES += \
More C++ porting, round 6 Port rojig-build and rpm-util to C++. Prep for using https://cxx.rs/
2020-12-19 18:29:13 +03:00
src/app/rpmostree-ex-builtin-commit2rojig.cxx \
Port rojig2commit to C++ Prep for using https://cxx.rs/
2020-12-19 18:48:44 +03:00
src/app/rpmostree-ex-builtin-rojig2commit.cxx \
Port compose-builtin-rojig to C++ Prep for using https://cxx.rs/
2020-12-19 19:03:32 +03:00
src/app/rpmostree-compose-builtin-rojig.cxx \
Add --enable-rojig, disable by default We're seeing some CI failures that I think are a bug in rojig. In the bigger picture...we never actually started using this, and I think longer term shipping os updates via containers probably makes more sense. I put a *lot* of effort into this code and it's pretty cool so it's hard to just delete it. And *maybe* someone out there is using it (but I doubt it). So rather than just deleting it entirely let's make it a build-time option. I verified that it builds at least.
2020-10-22 20:33:45 +03:00
$(NULL)
endif
buildsys: Make one big rpmostreeinternals.la, enable unit tests again 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.
2020-12-21 17:15:28 +03:00
nodist_librpmostreeinternals_la_SOURCES = $(dbus_built_sources) $(nodist_librpmostreepriv_sources)
buildsys: Compile daemon code directly with binary 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.
2020-12-17 01:17:49 +03:00
Convert some code to compile in C++ mode This is part of investigating using https://cxx.rs/ In order to make this really work, we need to convert some of our C code to C++ so we can include cxx.rs-generated code. This starts by converting just two files as a starting point. I did the minimal porting; I didn't try to actually rewrite them to resemble modern C++, just "C in C++ mode".
2020-11-22 22:55:06 +03:00
rpmostree_common_cflags = -I$(srcdir)/src/app -I$(srcdir)/src/daemon \
Merge daemon binary into main binary The actual problem I am trying to fix with this is fallout from the introduction of `/usr/libexec/rpm-ostreed`, which required a SELinux policy change. Specifically for CentOS, the base policy is rev'd slowly. My hope was that by merging the daemon code back into `/usr/bin/rpm-ostree` which is labeled `install_exec_t`, starting via systemd would do the right thing. It turns out that doesn't happen. Now later, I'm picking this patch back up because I want to do multprocessing in the daemon (and in the core), and it makes sense to share code between them, because multiprocessing will need to go through a re-exec path. Another benefit is we avoid duplicated text (libglnx, internal helpers) between the two binaries. Closes: #292 Approved by: jlebon
2016-05-27 21:46:46 +03:00
-I$(srcdir)/src/lib -I$(srcdir)/src/libpriv -I$(libglnx_srcpath) \
buildsys: Compile daemon code directly with binary 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.
2020-12-17 01:17:49 +03:00
-DG_LOG_DOMAIN=\"rpm-ostreed\" \
-DLIBDIR=\"$(libdir)\" -DPKGLIBDIR=\"$(pkglibdir)\" \
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-01-29 22:47:48 +03:00
-I $(top_srcdir)/libdnf \
build-sys: Cleanly split up deps of public shlib vs internals First, the public shared library only depends on a few things (not the libdnf dependencies) so let's ensure we only link it to those libraries. And then, I realized we don't actually need the libdnf dependencies here - I think I only added those back here when trying vainly to keep the C unit tests working. But we don't have those anymore! So we can delete the duplication and fully rely on Cargo taking care of libdnf. Conceptually for a static library we don't "link" it against anything in Automake, that happens at the final stage with the Rust linker.
2021-01-30 00:56:02 +03:00
$(PKGDEP_LIBRPMOSTREE_CFLAGS) $(PKGDEP_RPMOSTREE_CFLAGS)
buildsys: Make one big rpmostreeinternals.la, enable unit tests again 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.
2020-12-21 17:15:28 +03:00
rpmostree_bin_common_cflags = $(rpmostree_common_cflags)
build-sys: Cleanly split up deps of public shlib vs internals First, the public shared library only depends on a few things (not the libdnf dependencies) so let's ensure we only link it to those libraries. And then, I realized we don't actually need the libdnf dependencies here - I think I only added those back here when trying vainly to keep the C unit tests working. But we don't have those anymore! So we can delete the duplication and fully rely on Cargo taking care of libdnf. Conceptually for a static library we don't "link" it against anything in Automake, that happens at the final stage with the Rust linker.
2021-01-30 00:56:02 +03:00
rpmostree_common_libs = libglnx.la librpmostree-1.la librpmostreecxxrs.la
lib: Don't link to libdnf Prep for "Rust-as-main", where I want to build libdnf statically. And this really completes the "library thinout" story because now we avoid dragging our *private* `libdnf.so` into the caller's address space, which can cause potential conflicts if they're also linking the system one. (Which could easily occur with something like gnome-software) All we were using libdnf for (indirectly via libsolv) is comparing version strings but librpm can already do that for us.
2021-01-27 21:57:44 +03:00
Change main entrypoint to be Rust We now have bidirectional calling between Rust and C++, but we are generating two static libraries that we then link together with a tiny C++ `main.cxx`. Let's make another huge leap towards oxdiation by having Rust be the entrypoint. This way cargo natively takes care of linking the internal Rust library, and our C++ internals become the library. In other words, we've now fully inverted from "C app with internal Rust library" to "Rust binary with internal C++ library". In order to make this work though we have to finally kill the C unit tests. But mostly everything covered there is either being converted to Rust, or covered elsewhere anyways. Now as the doc comments in `main.rs` say...this is a bit awkward because all the CLI code is still in C++. Porting stuff to use e.g. `structopt` natively would be a bit of a slog. For now, we basically rely on the fact that the Rust-native CLIs are all hidden commands. Update submodule: libdnf
2021-01-26 14:34:59 +03:00
rpmostree_bin_common_libs = librpmostreeinternals.la $(rpmostree_common_libs)
buildsys: Make one big rpmostreeinternals.la, enable unit tests again 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.
2020-12-21 17:15:28 +03:00
librpmostreeinternals_la_CFLAGS = $(AM_CFLAGS) $(rpmostree_common_cflags)
librpmostreeinternals_la_CXXFLAGS = $(AM_CXXFLAGS) $(rpmostree_common_cflags)
rust: Link to our C/C++ dependencies and internal library This allows us to fully use cxx-rs with `extern "C++"`. Now we do call back into the C/C++ today, but it only works outside of cargo/Rust's knowledge. Most notably, it means we can't use our C code in `cargo test`. And that's a problem for moving some C/C++ code to Rust, because we want to port the unit tests too. For now, re-declare our dependencies and part of the build system inside the Cargo build. However, this is also an important step towards using Cargo as our *sole* build system. We don't add build dependencies too often, so the short term duplication should be OK. However, a major unfortunate side effect of this is that we now need to serialize the build process; almost all the C/C++ comes first (`librpmostreeinternals.la`) and then the Rust build, then we finally generate the executable with both. The only way out of this really is to move more of the C/C++ build into Cargo, and we probably want to refactor into internal crates.
2021-01-23 18:32:05 +03:00
librpmostreeinternals_la_LIBADD = $(rpmostree_common_libs)
Split out postprocess+commit to separate script As this logic is of most interest to potential other consumers; it's not entangled with yum for example.
2014-01-16 16:26:54 +04:00
Initial import from pkgsys-ostree
2013-12-22 04:41:30 +04:00
privdatadir=$(pkglibdir)
tmpfiles.d: rename and re-order According to tmpfiles.d(5), files should follow the convention <package>.conf or <package>-<part>.conf. So we rename tmpfiles-ostree-integration.conf to rpm-ostree-0-integration.conf. The 0 index is so that the autovar conf created by postprocess is sourced *after* this one, so that `integration.conf` has higher precedence if there are duplicate entries. Closes: #325 Approved by: cgwalters
2016-06-15 23:30:11 +03:00
privdata_DATA = src/app/rpm-ostree-0-integration.conf
Add infrastructure for alternative name (currently nts) See https://github.com/projectatomic/rpm-ostree/issues/405 This patch adds an (off by default) `--enable-new-name` build option which currently defaults to `nts`. This is purely additive, and the intention is that we'll support the rpm-ostree name in perpetuity most likely. At the moment, we add a new name for: - /usr/bin/$name - The systemd unit file But we notably *don't* attempt to add a new name to the DBus API, as it'd be a lot more invasive of a patch, and less payoff (it's mostly just programs/scripts that interact with the DBus). Closes: #497 Approved by: jlebon
2016-10-19 21:24:40 +03:00
build-sys: Propagate Automake verbose mode to Rust/cargo This is analogous to commit c62058e54860165899581fa11de2d7a956bca7d5 which propagated `V=1` into `cmake`. Except if the build *isn't* verbose (for local development), let's not force `--verbose` on for Rust. Closes: #1583 Approved by: jlebon
2018-09-26 17:23:48 +03:00
# Propagate automake verbose mode
cargo_build = $(cargo) build $(if $(subst 0,,$(V)),--verbose,)
With vendored source, use cargo build --offline 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.
2021-01-11 21:25:51 +03:00
if BUILDOPT_PREBUILT_BINDINGS
cargo_build += "--offline"
endif
build-sys: Propagate Automake verbose mode to Rust/cargo This is analogous to commit c62058e54860165899581fa11de2d7a956bca7d5 which propagated `V=1` into `cmake`. Except if the build *isn't* verbose (for local development), let's not force `--verbose` on for Rust. Closes: #1583 Approved by: jlebon
2018-09-26 17:23:48 +03:00
Default to sqlite rpmdb backend on f34 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.
2020-12-22 01:27:52 +03:00
if BUILDOPT_ENABLE_SQLITE_RPMDB_DEFAULT
cargo_build += --features sqlite-rpmdb-default
endif
Change main entrypoint to be Rust We now have bidirectional calling between Rust and C++, but we are generating two static libraries that we then link together with a tiny C++ `main.cxx`. Let's make another huge leap towards oxdiation by having Rust be the entrypoint. This way cargo natively takes care of linking the internal Rust library, and our C++ internals become the library. In other words, we've now fully inverted from "C app with internal Rust library" to "Rust binary with internal C++ library". In order to make this work though we have to finally kill the C unit tests. But mostly everything covered there is either being converted to Rust, or covered elsewhere anyways. Now as the doc comments in `main.rs` say...this is a bit awkward because all the CLI code is still in C++. Porting stuff to use e.g. `structopt` natively would be a bit of a slog. For now, we basically rely on the fact that the Rust-native CLIs are all hidden commands. Update submodule: libdnf
2021-01-26 14:34:59 +03:00
if RUST_DEBUG
cargo_target_dir=debug
else
cargo_target_dir=release
endif
Move the main Rust infra (i.e. Cargo.toml) to the toplevel 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
2020-12-08 21:29:05 +03:00
LIBRPMOSTREE_RUST_SRCS = $(shell find rust/src/ -name '*.rs') Cargo.toml Cargo.lock cbindgen.toml
rust: Link to our C/C++ dependencies and internal library This allows us to fully use cxx-rs with `extern "C++"`. Now we do call back into the C/C++ today, but it only works outside of cargo/Rust's knowledge. Most notably, it means we can't use our C code in `cargo test`. And that's a problem for moving some C/C++ code to Rust, because we want to port the unit tests too. For now, re-declare our dependencies and part of the build system inside the Cargo build. However, this is also an important step towards using Cargo as our *sole* build system. We don't add build dependencies too often, so the short term duplication should be OK. However, a major unfortunate side effect of this is that we now need to serialize the build process; almost all the C/C++ comes first (`librpmostreeinternals.la`) and then the Rust build, then we finally generate the executable with both. The only way out of this really is to move more of the C/C++ build into Cargo, and we probably want to refactor into internal crates.
2021-01-23 18:32:05 +03:00
# FIXME - build all this code in a rpmostree-sys crate, or just move all the C/C++ build
# to Rust. Currently this forces build system serialization
Change main entrypoint to be Rust We now have bidirectional calling between Rust and C++, but we are generating two static libraries that we then link together with a tiny C++ `main.cxx`. Let's make another huge leap towards oxdiation by having Rust be the entrypoint. This way cargo natively takes care of linking the internal Rust library, and our C++ internals become the library. In other words, we've now fully inverted from "C app with internal Rust library" to "Rust binary with internal C++ library". In order to make this work though we have to finally kill the C unit tests. But mostly everything covered there is either being converted to Rust, or covered elsewhere anyways. Now as the doc comments in `main.rs` say...this is a bit awkward because all the CLI code is still in C++. Porting stuff to use e.g. `structopt` natively would be a bit of a slog. For now, we basically rely on the fact that the Rust-native CLIs are all hidden commands. Update submodule: libdnf
2021-01-26 14:34:59 +03:00
rpm-ostree: Makefile $(LIBRPMOSTREE_RUST_SRCS) librpmostreeinternals.la
Move the main Rust infra (i.e. Cargo.toml) to the toplevel 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
2020-12-08 21:29:05 +03:00
$(cargo_build) $(CARGO_RELEASE_ARGS)
Change main entrypoint to be Rust We now have bidirectional calling between Rust and C++, but we are generating two static libraries that we then link together with a tiny C++ `main.cxx`. Let's make another huge leap towards oxdiation by having Rust be the entrypoint. This way cargo natively takes care of linking the internal Rust library, and our C++ internals become the library. In other words, we've now fully inverted from "C app with internal Rust library" to "Rust binary with internal C++ library". In order to make this work though we have to finally kill the C unit tests. But mostly everything covered there is either being converted to Rust, or covered elsewhere anyways. Now as the doc comments in `main.rs` say...this is a bit awkward because all the CLI code is still in C++. Porting stuff to use e.g. `structopt` natively would be a bit of a slog. For now, we basically rely on the fact that the Rust-native CLIs are all hidden commands. Update submodule: libdnf
2021-01-26 14:34:59 +03:00
ln -sfr target/$(cargo_target_dir)/rpm-ostree $@
Move the main Rust infra (i.e. Cargo.toml) to the toplevel 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
2020-12-08 21:29:05 +03:00
EXTRA_DIST += $(LIBRPMOSTREE_RUST_SRCS)
Change main entrypoint to be Rust We now have bidirectional calling between Rust and C++, but we are generating two static libraries that we then link together with a tiny C++ `main.cxx`. Let's make another huge leap towards oxdiation by having Rust be the entrypoint. This way cargo natively takes care of linking the internal Rust library, and our C++ internals become the library. In other words, we've now fully inverted from "C app with internal Rust library" to "Rust binary with internal C++ library". In order to make this work though we have to finally kill the C unit tests. But mostly everything covered there is either being converted to Rust, or covered elsewhere anyways. Now as the doc comments in `main.rs` say...this is a bit awkward because all the CLI code is still in C++. Porting stuff to use e.g. `structopt` natively would be a bit of a slog. For now, we basically rely on the fact that the Rust-native CLIs are all hidden commands. Update submodule: libdnf
2021-01-26 14:34:59 +03:00
ALL_LOCAL_HOOKS += rpm-ostree
CLEANFILES += rpm-ostree
Add support for YAML treefiles Let's modernize and start supporting YAML treefiles. I'll dare make the sweeping generalization that most people would prefer reading and writing YAML over JSON. This takes bits from coreos-assembler[1] that know how to serialize a YAML file and spit it back out as a JSON and makes it into a shared lib that we can link against. We could use this eventually for JSON inputs as well to force a validation check before composing. If we go this route, we could then turn on `--enable-rust` in FAHC for now and drop the duplicate code in coreos-assembler. [1] https://github.com/cgwalters/coreos-assembler Closes: #1377 Approved by: cgwalters
2018-05-31 23:31:22 +03:00
Rework bindgen/cxx.rs usage and CI build 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.
2020-12-31 19:55:19 +03:00
# cbindgen + cxx.rs
Makefile.bindings: Also generate pure rust/cxx.h This is necessary in order to use `rust::` in our header files that are also used by bindings.
2021-01-27 04:35:37 +03:00
binding_generated_sources = rpmostree-rust.h rpmostree-cxxrs.h rpmostree-cxxrs.cxx rust/cxx.h
Fix and improve support for rpmostree-rust.h being pre-generated 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.
2020-12-11 18:09:57 +03:00
if BUILDOPT_PREBUILT_BINDINGS
Rework bindgen/cxx.rs usage and CI build 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.
2020-12-31 19:55:19 +03:00
# In this case we shipped prebuilt versions in the source tarball
Fix and improve support for rpmostree-rust.h being pre-generated 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.
2020-12-11 18:09:57 +03:00
rpmostree-rust.h:
ln -sfr rpmostree-rust-prebuilt.h $@
Rework bindgen/cxx.rs usage and CI build 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.
2020-12-31 19:55:19 +03:00
rpmostree-cxxrs.h:
ln -sfr rpmostree-cxxrs-prebuilt.h $@
rpmostree-cxxrs.cxx:
ln -sfr rpmostree-cxxrs-prebuilt.cxx $@
Makefile.bindings: Also generate pure rust/cxx.h This is necessary in order to use `rust::` in our header files that are also used by bindings.
2021-01-27 04:35:37 +03:00
rust/cxx.h:
ln -sfr rust/cxx-prebuilt.h $@
Fix and improve support for rpmostree-rust.h being pre-generated 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.
2020-12-11 18:09:57 +03:00
else
Rework bindgen/cxx.rs usage and CI build 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.
2020-12-31 19:55:19 +03:00
include Makefile.bindings
Fix and improve support for rpmostree-rust.h being pre-generated 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.
2020-12-11 18:09:57 +03:00
endif
cxxrs: Work around failure with -Werror=missing-declarations See https://github.com/dtolnay/cxx/issues/590
2020-12-22 17:56:15 +03:00
noinst_LTLIBRARIES += librpmostreecxxrs.la
librpmostreecxxrs_la_SOURCES = rpmostree-cxxrs.h rpmostree-cxxrs.cxx
# Suppress missing-declarations because https://github.com/dtolnay/cxx/issues/590
librpmostreecxxrs_la_CXXFLAGS = $(AM_CXXFLAGS) $(rpmostree_common_cflags) -Wno-missing-declarations
librpmostreecxxrs_la_LIBADD = -lstdc++
Rework bindgen/cxx.rs usage and CI build 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.
2020-12-31 19:55:19 +03:00
GITIGNOREFILES += $(binding_generated_sources)
BUILT_SOURCES += $(binding_generated_sources)
Use cbindgen If we're going to scale out our oxidation, let's follow the path of Firefox (and other projects) further and use cbindgen: https://github.com/eqrion/cbindgen It's actually nice that `cbindgen` is packaged today in Fedora, but I doubt it is elsewhere; we may end up needing to push that forward, or just vendor it via a `build.rs` script and Cargo. I chose to rename things to `ROR`/`ror_` since it's shorter. I am tempted a bit to rename our internal functions to just `ro_` to or so. Closes: #1516 Approved by: jlebon
2018-08-24 17:42:31 +03:00
Change main entrypoint to be Rust We now have bidirectional calling between Rust and C++, but we are generating two static libraries that we then link together with a tiny C++ `main.cxx`. Let's make another huge leap towards oxdiation by having Rust be the entrypoint. This way cargo natively takes care of linking the internal Rust library, and our C++ internals become the library. In other words, we've now fully inverted from "C app with internal Rust library" to "Rust binary with internal C++ library". In order to make this work though we have to finally kill the C unit tests. But mostly everything covered there is either being converted to Rust, or covered elsewhere anyways. Now as the doc comments in `main.rs` say...this is a bit awkward because all the CLI code is still in C++. Porting stuff to use e.g. `structopt` natively would be a bit of a slog. For now, we basically rely on the fact that the Rust-native CLIs are all hidden commands. Update submodule: libdnf
2021-01-26 14:34:59 +03:00
# And install our binary
install-rpmostree-hook:
install -d -m 0755 $(DESTDIR)$(bindir)
install -m 0755 -t $(DESTDIR)$(bindir) target/release/rpm-ostree
INSTALL_EXEC_HOOKS += install-rpmostree-hook
build-sys: Add a `rust-test` target I often am editing just the Rust code, and want the fast iteration feedback of a `cargo test` - don't want to pay the cost of full optimization (particularly LTO) for the release build, and I *just* want to run the Rust tests. Basically if you're editing our Rust code a lot, this target is your friend. Closes: #1585 Approved by: jlebon
2018-09-26 17:43:18 +03:00
# Wraps `cargo test`. This is always a debug non-release build;
# the main thing here is we still drop the `target` dir in our build
# directory, since we nominally support srcdir != builddir.
make/rust-test: fix linking and loading This fixes link dependencies and build-libraries path, in order to make Rust tests work. It also introduces an additional wildcard target to allow specifying a test filter to cargo.
2021-01-28 13:13:57 +03:00
rust-test: $(binding_generated_sources) $(dbus_built_sources) $(librpmostree_rust_path) librpmostreecxxrs.la librpmostreeinternals.la
LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:@abs_top_builddir@/.libs/" cargo test
rust-test-%: $(binding_generated_sources) $(dbus_built_sources) $(librpmostree_rust_path) librpmostreecxxrs.la librpmostreeinternals.la
LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:@abs_top_builddir@/.libs/" cargo test -- $*
.PHONY: rust-test rust-test-%
Reference in New Issue Copy Permalink