keremet/rpm-ostree
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
9c3864b97e
rpm-ostree/configure.ac

216 lines
7.3 KiB
Plaintext
Raw Normal View History

Initial import from pkgsys-ostree
2013-12-22 04:41:30 +04:00
AC_PREREQ([2.63])
Move release instructions to RELEASE.md The instructions for doing a release were outdated. Take the opportunity to just move it to a dedicated markdown file and breaking it out to make it easier to follow. This is one step short of using a release checklist like some of the other CoreOS projects do. This is a good base to eventually do that if we want.
2020-06-19 21:09:42 +03:00
dnl
dnl SEE RELEASE.md FOR INSTRUCTIONS ON HOW TO DO A RELEASE.
dnl
Release 2021.1
2021-01-18 22:24:46 +03:00
m4_define([year_version], [2021])
Update configure.ac Co-authored-by: Jonathan Lebon <jonathan@jlebon.com>
2021-01-18 22:48:40 +03:00
m4_define([release_version], [1])
lib: Add version macros and version checking function The version checking function in particular is really useful for people doing `from gi.repository import RpmOstree`, which we'd like at least some things like Anaconda and Pungi to do. Closes: #891 Approved by: jlebon
2017-07-21 20:32:58 +03:00
m4_define([package_version], [year_version.release_version])
configure: Update contact email atomic-devel@ is dead.
2021-01-11 21:28:19 +03:00
AC_INIT([rpm-ostree], [package_version], [coreos@lists.fedoraproject.org])
Initial import from pkgsys-ostree
2013-12-22 04:41:30 +04:00
AC_CONFIG_HEADER([config.h])
tests: Enable glib-tap.mk These files were taken from json-glib, around the era of this commit: https://git.gnome.org/browse/json-glib/tree/build/autotools?id=2779d537492f1902d71cf648631238110b62b311 Unfortunately, this involved hacking it up a bit: - I couldn't easily use `nobase` for the data, so I deleted that. Test data goes in the installed-tests dir. - Delete duplicated predeclared variables; we're using nonrecursive make. - Ensure we run each test in its own tmpdir
2014-12-18 02:11:47 +03:00
AC_CONFIG_MACRO_DIR([buildutil])
Initial import from pkgsys-ostree
2013-12-22 04:41:30 +04:00
AC_CONFIG_AUX_DIR([build-aux])
lib: Add version macros and version checking function The version checking function in particular is really useful for people doing `from gi.repository import RpmOstree`, which we'd like at least some things like Anaconda and Pungi to do. Closes: #891 Approved by: jlebon
2017-07-21 20:32:58 +03:00
dnl Versioning information
AC_SUBST([YEAR_VERSION], [year_version])
AC_SUBST([RELEASE_VERSION], [release_version])
AC_SUBST([PACKAGE_VERSION], [package_version])
Initial import from pkgsys-ostree
2013-12-22 04:41:30 +04:00
automake: squash warnings re. subdir-objects During autoreconf, automake would emit many warnings regarding the option 'subdir-objects' being disabled. We squash those warnings by enabling the option. We also fix Makefile.am so that it includes the patched libglnx Makefile rather than the original one, which would cause libglnx output to be placed in the literal dir './$(libglnx_srcpath)'.
2015-09-11 16:33:46 +03:00
AM_INIT_AUTOMAKE([1.11 -Wno-portability foreign no-define tar-ustar no-dist-gzip dist-xz subdir-objects])
Initial import from pkgsys-ostree
2013-12-22 04:41:30 +04:00
AM_MAINTAINER_MODE([enable])
AM_SILENT_RULES([yes])
AC_USE_SYSTEM_EXTENSIONS
AC_SYS_LARGEFILE
AC_PROG_CC
build-sys: Inject Automake's default CXXFLAGS to libdnf by default Today I was trying to use gdb and noticed my libdnf build didn't have debuginfo. Now, I thought that's what `-DCMAKE_BUILD_TYPE=RelWithDebugInfo` was doing but...I have no idea right now where I got that. I looked at RPM builds, and the way this works is it exports CXXFLAGS. Now for our C code, our defaults actually come from Autoconf. Let's do the beautiful hack of telling Autoconf we're going to use C++ so it sets `CXXFLAGS` for us. Closes: #1586 Approved by: jlebon
2018-09-27 00:32:10 +03:00
dnl we don't today use C++ in rpm-ostree, only in libdnf,
dnl but this has the side effect of setting CXXFLAGS with -g
dnl if not set, which we definitely want; cmake doesn't do that.
AC_PROG_CXX
Initial import from pkgsys-ostree
2013-12-22 04:41:30 +04:00
AM_PROG_CC_C_O
build: Sync up warnings with ostree Mostly to pick up `-Werror=incompatible-pointer-types`. Closes: #542 Approved by: jlebon
2016-12-07 23:30:22 +03:00
dnl Keep this in sync with the version in ostree
build-sys: Sync CFLAGS with libostree In particular this pulls in `-fno-strict-aliasing`. See https://github.com/ostreedev/ostree/pull/1384 Closes: #1156 Approved by: jlebon
2017-12-15 17:52:48 +03:00
AS_IF([echo "$CFLAGS" | grep -q -E -e '-Werror($| )'], [], [
build: Import attributes.m4 copy from systemd, update warnings This matches https://github.com/ostreedev/ostree/pull/431 I also merged in the `-Wint-conversion` here since we build fine with it now. Closes: #420 Approved by: jlebon
2016-08-06 16:28:43 +03:00
CC_CHECK_FLAGS_APPEND([WARN_CFLAGS], [CFLAGS], [\
build-sys: Sync CFLAGS with libostree In particular this pulls in `-fno-strict-aliasing`. See https://github.com/ostreedev/ostree/pull/1384 Closes: #1156 Approved by: jlebon
2017-12-15 17:52:48 +03:00
-pipe \
-Werror=empty-body \
"-Werror=format=2 -Werror=format-security -Werror=format-nonliteral" \
-Werror=pointer-arith -Werror=init-self \
-Werror=missing-declarations \
-Werror=return-type \
-Werror=switch \
-Werror=overflow \
-Werror=parenthesis \
-Werror=undef \
-Werror=misleading-indentation \
Use cxx-rs for core.rs 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.
2020-12-11 04:21:33 +03:00
-Werror=missing-include-dirs \
build-sys: Sync CFLAGS with libostree In particular this pulls in `-fno-strict-aliasing`. See https://github.com/ostreedev/ostree/pull/1384 Closes: #1156 Approved by: jlebon
2017-12-15 17:52:48 +03:00
-Wstrict-aliasing=2 \
-Werror=unused-result \
])])
Initial import from pkgsys-ostree
2013-12-22 04:41:30 +04:00
AC_SUBST(WARN_CFLAGS)
tests: Disable ASAN leak checks Right now we're far from leak free, and I want to use ASAN as a sanity checker, not a leak checker. Closes: #576 Approved by: jlebon
2017-01-17 21:29:48 +03:00
AC_MSG_CHECKING([for -fsanitize=address in CFLAGS])
if echo $CFLAGS | grep -q -e -fsanitize=address; then
AC_MSG_RESULT([yes])
using_asan=yes
else
AC_MSG_RESULT([no])
fi
AM_CONDITIONAL(BUILDOPT_ASAN, [test x$using_asan = xyes])
Initial import from pkgsys-ostree
2013-12-22 04:41:30 +04:00
# Initialize libtool
LT_PREREQ([2.2.4])
LT_INIT([disable-static])
Show capability list with --version option
2014-11-26 14:02:19 +03:00
RPM_OSTREE_FEATURES=""
AC_SUBST([RPM_OSTREE_FEATURES])
Initial import from pkgsys-ostree
2013-12-22 04:41:30 +04:00
PKG_PROG_PKG_CONFIG
Bump GIO requirement to 2.40 to match ostree
2015-08-14 19:22:45 +03:00
# Remember to update AM_CPPFLAGS in Makefile.am when bumping GIO req.
Initial import from pkgsys-ostree
2013-12-22 04:41:30 +04:00
PKG_CHECK_MODULES(PKGDEP_GIO_UNIX, [gio-unix-2.0])
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
# librepo libsolv etc. are libdnf dependencies
build-sys: Bump glib dependency This matches reality; I picked what's in CentOS 7 mainline today. More importantly this also fixes a build error with `-Werror=undef` because we had a trailing underscore `_` at the end and never noticed. Closes: #1156 Approved by: jlebon
2017-12-15 17:50:43 +03:00
PKG_CHECK_MODULES(PKGDEP_RPMOSTREE, [gio-unix-2.0 >= 2.50.0 json-glib-1.0
Add new `ex initramfs-etc` command This command allows users to cheaply inject configuration files in the initramfs stage without having to regenerate the whole initramfs (or even a new OSTree commit). This will be useful for configuring services involved in bringing up the root block device. ``` $ echo 'hello world' > /etc/foobar $ rpm-ostree ex initramfs-etc --track /etc/foobar Staging deployment... done Run "systemctl reboot" to start a reboot $ rpm-ostree status State: idle Deployments: ostree://fedora:fedora/x86_64/coreos/testing-devel Version: 32.20200716.dev.1 (2020-07-16T02:47:29Z) Commit: 9a817d75bef81b955179be6e602d1e6ae350645b6323231a62ba2ee6e5b9644b GPGSignature: (unsigned) InitramfsEtc: /etc/foobar ● ostree://fedora:fedora/x86_64/coreos/testing-devel Version: 32.20200716.dev.1 (2020-07-16T02:47:29Z) Commit: 9a817d75bef81b955179be6e602d1e6ae350645b6323231a62ba2ee6e5b9644b GPGSignature: (unsigned) $ reboot (boot into rd.break) sh-5.0# cat /etc/foobar hello world ``` See the libostree side of this at: https://github.com/ostreedev/ostree/pull/2155 Lots more discussions in: https://github.com/coreos/fedora-coreos-tracker/issues/94 Closes: #1930
2020-07-25 00:35:01 +03:00
ostree-1 >= 2020.7
core: Initial implementation of %posttrans using bwrap+rofiles-fuse In order to make many things work, we need to run scripts. Short version: For now, we: - Run `%posttrans` - Treat most `%post` as the same as `%posttrans` - Ignore `%preun` and such since we never uninstall Most importantly though, we start to build up an "override" list for script handling. Currently it's just a blacklist of scripts we don't need. Significant work here would be needed to run Lua scripts, so far I've been able to just skip them. Closes: #338 Approved by: jlebon
2016-06-17 22:14:24 +03:00
libsystemd
Add polkit support This allows non-root users access to the rpm-ostree daemon, which is a pre-requirement for gnome-software rpm-ostree support. Closes: #745 Closes: #825 Approved by: cgwalters
2017-06-09 13:52:01 +03:00
polkit-gobject-1
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 librepo libsolv libsolvext sqlite3 gpgme modulemd-2.0 json-c libcurl openssl
build: Add `libarchive` to pkg-config deps For some reason my CD builder didn't trigger this, but we do actually need `-larchive` (and we want to have the dependency metadata so packagers know to BuildDepends on it).
2016-01-12 19:22:16 +03:00
libarchive])
app: Add support for passing URLs to RPMs This teaches the client to fetch packages from URLs directly so that one doesn't have to `curl` first and then install. Supported anywhere package filenames are allowed (notably: `install` and `override replace`). One neat things about this is that we download the file into an `O_TMPFILE` and then pass on ownership of that fd directly to the daemon. So at no point are the packages actually laying visible on the system. (Assuming the filesystem supports `O_TMPFILE` that is). This adds direct linking to libcurl and openssl, two libraries which we were already pulling in indirectly. Closes: #1508 Approved by: cgwalters
2018-08-18 00:34:02 +03:00
# We just keep rust-specific deps separate for better tracking
# The `libcurl` one is redundant since we already require it for libostree. `openssl`
# is required by libcurl anyway, but we need to link to it directly too because
# curl-rust uses it.
PKG_CHECK_MODULES(PKGDEP_RPMOSTREE_RS, [libcurl openssl])
unpacker: Build with older libarchive without zstd It's not in RHEL8.1, and I'm trying to rebase rpm-ostree.
2019-10-15 18:16:06 +03:00
dnl RHEL8.1 has old libarchive
AS_IF([pkg-config --atleast-version=3.3.3 libarchive],
[AC_DEFINE([HAVE_LIBARCHIVE_ZSTD], 1, [Define if we have libarchive with zstd])])
Implement file triggers (%transfiletriggerin) for layered pkgs File triggers are a post-RHEL7 thing; more information at http://rpm.org/user_doc/file_triggers.html There are two notable users I've been testing this with; `glib2` and `vagrant`. The `vagrant` one is more immediately urgent, since it makes `vagrant-libvirt` work, which I currently rely on for my workstation dev. I've tested things successfully with `vagrant`, and I did verify that we run the `glib2` ones when doing `rpm-ostree ex container`. Long term, more transaction file triggers are likely to live in "base" packages like `glib2`. We don't implement those yet, but extending this to do that shouldn't be too hard. There was *significant* what I'd call reverse engineering of the implementation in librpm. The file triggers code there is spread out and abstracted in a few different places in the code. I found trying to understand what header values were involved to be quite tricky. There are some corner cases like multiple patterns that I *think* this does correctly, but could use more validation. The main question I had was - is it required that the patterns for e.g. `%transfiletriggerin` and `%transfiletriggerun` be identical? Closes: https://github.com/projectatomic/rpm-ostree/issues/648 Closes: #869 Approved by: jlebon
2017-07-07 17:45:10 +03:00
dnl This is the current version in Fedora 25.
build-sys: Drop support for ancient librpm Here's where we stop caring about RHEL7's librpm. Closes: #1794 Approved by: jlebon
2019-03-21 05:54:52 +03:00
AS_IF([pkg-config --atleast-version=4.14.2 rpm], [], [AC_MSG_ERROR([librpm 4.14.2 required])])
Implement file triggers (%transfiletriggerin) for layered pkgs File triggers are a post-RHEL7 thing; more information at http://rpm.org/user_doc/file_triggers.html There are two notable users I've been testing this with; `glib2` and `vagrant`. The `vagrant` one is more immediately urgent, since it makes `vagrant-libvirt` work, which I currently rely on for my workstation dev. I've tested things successfully with `vagrant`, and I did verify that we run the `glib2` ones when doing `rpm-ostree ex container`. Long term, more transaction file triggers are likely to live in "base" packages like `glib2`. We don't implement those yet, but extending this to do that shouldn't be too hard. There was *significant* what I'd call reverse engineering of the implementation in librpm. The file triggers code there is spread out and abstracted in a few different places in the code. I found trying to understand what header values were involved to be quite tricky. There are some corner cases like multiple patterns that I *think* this does correctly, but could use more validation. The main question I had was - is it required that the patterns for e.g. `%transfiletriggerin` and `%transfiletriggerun` be identical? Closes: https://github.com/projectatomic/rpm-ostree/issues/648 Closes: #869 Approved by: jlebon
2017-07-07 17:45:10 +03:00
Detect whether zchunk (zck) is available at build time We don't *actually* use this ourself, but librepo does, and libdnf gets confused if librepo doesn't support it. This is the case in RHEL8 currently. Basically what breaks is trying to use the Fedora EPEL repo (has zchunk metadata) on RHEL CoreOS. And we have a test in kola that does this today.
2019-10-17 00:02:45 +03:00
dnl We don't *actually* use this ourself, but librepo does, and libdnf gets confused
dnl if librepo doesn't support it.
build-sys: Disable zchunk for libdnf if we don't have it Going to update rpm-ostree for RHEL 8.3, we did a huge bump in libdnf which now defaults to enabling zchunk in its build system. We added the infrastructure before to detect things, so propagate that to libdnf.
2020-05-14 03:38:48 +03:00
have_zchunk=no
Detect whether zchunk (zck) is available at build time We don't *actually* use this ourself, but librepo does, and libdnf gets confused if librepo doesn't support it. This is the case in RHEL8 currently. Basically what breaks is trying to use the Fedora EPEL repo (has zchunk metadata) on RHEL CoreOS. And we have a test in kola that does this today.
2019-10-17 00:02:45 +03:00
AS_IF([pkg-config --exists zck],
build-sys: Disable zchunk for libdnf if we don't have it Going to update rpm-ostree for RHEL 8.3, we did a huge bump in libdnf which now defaults to enabling zchunk in its build system. We added the infrastructure before to detect things, so propagate that to libdnf.
2020-05-14 03:38:48 +03:00
[have_zchunk=yes; AC_DEFINE([HAVE_ZCHUNK], 1, [Define if we have zchunk])])
Detect whether zchunk (zck) is available at build time We don't *actually* use this ourself, but librepo does, and libdnf gets confused if librepo doesn't support it. This is the case in RHEL8 currently. Basically what breaks is trying to use the Fedora EPEL repo (has zchunk metadata) on RHEL CoreOS. And we have a test in kola that does this today.
2019-10-17 00:02:45 +03:00
Initial import from pkgsys-ostree
2013-12-22 04:41:30 +04:00
AC_PATH_PROG([XSLTPROC], [xsltproc])
tests: Enable glib-tap.mk These files were taken from json-glib, around the era of this commit: https://git.gnome.org/browse/json-glib/tree/build/autotools?id=2779d537492f1902d71cf648631238110b62b311 Unfortunately, this involved hacking it up a bit: - I couldn't easily use `nobase` for the data, so I deleted that. Test data goes in the installed-tests dir. - Delete duplicated predeclared variables; we're using nonrecursive make. - Ensure we run each test in its own tmpdir
2014-12-18 02:11:47 +03:00
GLIB_TESTS
build-sys: Fix use of libglnx configure bits This fixes the build with `-Werror=undef` like we did in libostree. And man is this obscure black magic. Closes: #1156 Approved by: jlebon
2017-12-15 17:44:33 +03:00
LIBGLNX_CONFIGURE
tests: Enable glib-tap.mk These files were taken from json-glib, around the era of this commit: https://git.gnome.org/browse/json-glib/tree/build/autotools?id=2779d537492f1902d71cf648631238110b62b311 Unfortunately, this involved hacking it up a bit: - I couldn't easily use `nobase` for the data, so I deleted that. Test data goes in the installed-tests dir. - Delete duplicated predeclared variables; we're using nonrecursive make. - Ensure we run each test in its own tmpdir
2014-12-18 02:11:47 +03:00
Add a public shared library, with "rpm -qa" for commit functionality This will help build release engineering and other types of tools; for example, rather than parsing the output of `db diff`, one should be able to call an API. Initially, this adds the generic infrastructure for a public shared library, with a new function call to do the equivalent of `rpm -qa` on a particular OSTree commit. Closes: https://github.com/projectatomic/rpm-ostree/issues/117 Closes: https://github.com/projectatomic/rpm-ostree/pull/124
2015-03-20 03:45:30 +03:00
m4_ifdef([GOBJECT_INTROSPECTION_CHECK], [
GOBJECT_INTROSPECTION_CHECK([1.34.0])
])
AM_CONDITIONAL(BUILDOPT_INTROSPECTION, test "x$found_introspection" = xyes)
Import some code for using GJS This is forked from gnome-continuous.
2014-01-03 22:15:12 +04:00
build: Work without gtk-doc installed This follows the pattern used by e.g. glib. If people (commonly embedded systems) don't want docs, we should support that. Pull request: #235 Approved by: jlebon
2016-03-15 21:03:32 +03:00
m4_ifdef([GTK_DOC_CHECK], [
doc: Add gtk-doc for new library
2015-04-09 00:20:50 +03:00
GTK_DOC_CHECK([1.15], [--flavour no-tmpl])
build: Work without gtk-doc installed This follows the pattern used by e.g. glib. If people (commonly embedded systems) don't want docs, we should support that. Pull request: #235 Approved by: jlebon
2016-03-15 21:03:32 +03:00
],[
AM_CONDITIONAL([ENABLE_GTK_DOC],[false])
])
doc: Add gtk-doc for new library
2015-04-09 00:20:50 +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
AC_ARG_ENABLE(sqlite_rpmdb_default,
AS_HELP_STRING([--enable-sqlite-rpmdb-default],
[Default to sqlite rpmdb backend (default: no)]),,
[enable_sqlite_rpmdb_default=no])
AM_CONDITIONAL(BUILDOPT_ENABLE_SQLITE_RPMDB_DEFAULT, test x$enable_sqlite_rpmdb_default = xyes)
build-sys: Always enable compose tooling There's no reason to separate it anymore. Closes: #1794 Approved by: jlebon
2019-03-21 05:56:47 +03:00
RPM_OSTREE_FEATURES="$RPM_OSTREE_FEATURES compose"
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
build: Hook up bash completions Follow-up to #1499. This is mostly based on https://github.com/ostreedev/ostree/pull/1077. Closes: #1772 Approved by: rfairley
2019-03-06 20:31:36 +03:00
PKG_CHECK_VAR(BASH_COMPLETIONSDIR, [bash-completion], [completionsdir],,
build: Move completions to /usr/share rdgo is choking on this right now because, even though we added `/usr/share/bash-completion` to the list of dirs to check in the spec file[1], we don't have `bash-completion` installed in the buildroot, so the `completionsdir` pkgconfig var isn't defined and we end up defaulting to `/etc/bash_completion.d`. el7's bash (not that it matters much now after #1785) is indeed new enough to know that location. See also https://github.com/ostreedev/ostree/pull/1083. [1] https://src.fedoraproject.org/rpms/rpm-ostree/pull-request/30 Closes: #1786 Approved by: rfairley
2019-03-14 17:47:20 +03:00
BASH_COMPLETIONSDIR="${datadir}/bash-completion/completions")
build: Hook up bash completions Follow-up to #1499. This is mostly based on https://github.com/ostreedev/ostree/pull/1077. Closes: #1772 Approved by: rfairley
2019-03-06 20:31:36 +03:00
AC_SUBST(BASH_COMPLETIONSDIR)
build-sys: Hard require Rust As something that manages your base operating system, we care about reliability, predictability, as well as performance and low-level access to native operating system facilities. The C programming language is great for the latter two, but fails at providing a truly memory-safe environment. Rust is fairly unique in providing a language that doesn't carry a runtime, so we can gradually "oxidize" and convert our C code without imposing additional overhead. It's also got a lot of modern design niceties, like not having a null pointer. Let's pull the trigger here and hard require Rust. It's the programming language I personally want to be primarily writing in for years to come. This is also in line with a recent trend of reducing our experimental/optional matrix. Closes: #1509 Approved by: jlebon
2018-08-20 17:40:57 +03:00
AC_PATH_PROG([cargo], [cargo])
AS_IF([test -z "$cargo"], [AC_MSG_ERROR([cargo is required for --enable-rust])])
AC_PATH_PROG([rustc], [rustc])
AS_IF([test -z "$rustc"], [AC_MSG_ERROR([rustc is required for --enable-rust])])
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
dnl See comment in install-extra-builddeps.sh
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
AM_CONDITIONAL(BUILDOPT_PREBUILT_BINDINGS, [test -f rpmostree-rust-prebuilt.h])
build: Fix building rust in debug mode When building in `debug` mode, `RUST_DEBUG` was still turned off because `rust_debug_release` was set to `yes`, not `debug`. Fix this by tweaking how `--enable-rust-debug` works: when it's *not* provided, we default to the `$CFLAGS` detection logic. Otherwise, it overrides it. Closes: #1514 Approved by: cgwalters
2018-08-22 18:32:54 +03:00
AC_MSG_CHECKING(whether to build in debug mode)
debug_release=release
if $(echo $CFLAGS |grep -q -E "(-O0|-Og)"); then
debug_release=debug
fi
AC_MSG_RESULT($debug_release)
build-sys: Hard require Rust As something that manages your base operating system, we care about reliability, predictability, as well as performance and low-level access to native operating system facilities. The C programming language is great for the latter two, but fails at providing a truly memory-safe environment. Rust is fairly unique in providing a language that doesn't carry a runtime, so we can gradually "oxidize" and convert our C code without imposing additional overhead. It's also got a lot of modern design niceties, like not having a null pointer. Let's pull the trigger here and hard require Rust. It's the programming language I personally want to be primarily writing in for years to come. This is also in line with a recent trend of reducing our experimental/optional matrix. Closes: #1509 Approved by: jlebon
2018-08-20 17:40:57 +03:00
dnl These bits based on gnome:librsvg/configure.ac
build-sys: Turn Rust LTO off by default, add --enable-lto flag For us, this is primarily right now a size issue. See: https://internals.rust-lang.org/t/rust-staticlibs-and-optimizing-for-size/5746 For more information, there are these two issues: https://github.com/rust-lang/cargo/issues/4349 https://bugzilla.mozilla.org/show_bug.cgi?id=1386371 The basic issue here is that a build with LTO off (and a trivial change to add a `println!` takes 14s here, and with it on takes 38s. However, with LTO off the stripped size of `librpmostree_rust.a` is `6M`, with LTO on it's `1.1M`. I named this `--enable-lto` as I'd like to investigate doing this for the C code too. Closes: #1664 Approved by: jlebon
2018-11-05 18:50:24 +03:00
dnl By default, we build in release mode (but without LTO!)
build-sys: Hard require Rust As something that manages your base operating system, we care about reliability, predictability, as well as performance and low-level access to native operating system facilities. The C programming language is great for the latter two, but fails at providing a truly memory-safe environment. Rust is fairly unique in providing a language that doesn't carry a runtime, so we can gradually "oxidize" and convert our C code without imposing additional overhead. It's also got a lot of modern design niceties, like not having a null pointer. Let's pull the trigger here and hard require Rust. It's the programming language I personally want to be primarily writing in for years to come. This is also in line with a recent trend of reducing our experimental/optional matrix. Closes: #1509 Approved by: jlebon
2018-08-20 17:40:57 +03:00
AC_ARG_ENABLE(rust-debug,
AC_HELP_STRING([--enable-rust-debug],
[Build Rust code with debugging information [default=no]]),
[rust_debug_release=$enableval],
build: Fix building rust in debug mode When building in `debug` mode, `RUST_DEBUG` was still turned off because `rust_debug_release` was set to `yes`, not `debug`. Fix this by tweaking how `--enable-rust-debug` works: when it's *not* provided, we default to the `$CFLAGS` detection logic. Otherwise, it overrides it. Closes: #1514 Approved by: cgwalters
2018-08-22 18:32:54 +03:00
[rust_debug_release=$debug_release])
dnl Canonicalize yes/no to debug/release
AS_IF([test x$rust_debug_release = xno ], [rust_debug_release=release])
AS_IF([test x$rust_debug_release = xyes ], [rust_debug_release=debug])
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
build: Fix building rust in debug mode When building in `debug` mode, `RUST_DEBUG` was still turned off because `rust_debug_release` was set to `yes`, not `debug`. Fix this by tweaking how `--enable-rust-debug` works: when it's *not* provided, we default to the `$CFLAGS` detection logic. Otherwise, it overrides it. Closes: #1514 Approved by: cgwalters
2018-08-22 18:32:54 +03:00
RUST_TARGET_SUBDIR=${rust_debug_release}
build-sys: Hard require Rust As something that manages your base operating system, we care about reliability, predictability, as well as performance and low-level access to native operating system facilities. The C programming language is great for the latter two, but fails at providing a truly memory-safe environment. Rust is fairly unique in providing a language that doesn't carry a runtime, so we can gradually "oxidize" and convert our C code without imposing additional overhead. It's also got a lot of modern design niceties, like not having a null pointer. Let's pull the trigger here and hard require Rust. It's the programming language I personally want to be primarily writing in for years to come. This is also in line with a recent trend of reducing our experimental/optional matrix. Closes: #1509 Approved by: jlebon
2018-08-20 17:40:57 +03:00
AC_SUBST([RUST_TARGET_SUBDIR])
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
AM_CONDITIONAL(RUST_DEBUG, [test "x$rust_debug_release" = "xdebug"])
build-sys: Hard require Rust As something that manages your base operating system, we care about reliability, predictability, as well as performance and low-level access to native operating system facilities. The C programming language is great for the latter two, but fails at providing a truly memory-safe environment. Rust is fairly unique in providing a language that doesn't carry a runtime, so we can gradually "oxidize" and convert our C code without imposing additional overhead. It's also got a lot of modern design niceties, like not having a null pointer. Let's pull the trigger here and hard require Rust. It's the programming language I personally want to be primarily writing in for years to come. This is also in line with a recent trend of reducing our experimental/optional matrix. Closes: #1509 Approved by: jlebon
2018-08-20 17:40:57 +03:00
dnl Unconditional now.
RPM_OSTREE_FEATURES="$RPM_OSTREE_FEATURES rust"
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
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
AC_ARG_ENABLE(rojig,
AC_HELP_STRING([--enable-rojig],
[Support for shipping ostree commits via RPMs [default=no]]))
AM_CONDITIONAL([BUILDOPT_ROJIG], test x$enable_rojig = xyes)
AM_COND_IF([BUILDOPT_ROJIG], [
RPM_OSTREE_FEATURES="$RPM_OSTREE_FEATURES rojig"
AC_DEFINE([BUILDOPT_ROJIG], 1, [Define if rojig is enabled])
])
build-sys: Hard require Rust As something that manages your base operating system, we care about reliability, predictability, as well as performance and low-level access to native operating system facilities. The C programming language is great for the latter two, but fails at providing a truly memory-safe environment. Rust is fairly unique in providing a language that doesn't carry a runtime, so we can gradually "oxidize" and convert our C code without imposing additional overhead. It's also got a lot of modern design niceties, like not having a null pointer. Let's pull the trigger here and hard require Rust. It's the programming language I personally want to be primarily writing in for years to come. This is also in line with a recent trend of reducing our experimental/optional matrix. Closes: #1509 Approved by: jlebon
2018-08-20 17:40:57 +03:00
dnl And propagate the release/debug type to cmake
cmake_args=-DCMAKE_BUILD_TYPE=RelWithDebugInfo
build: Fix building rust in debug mode When building in `debug` mode, `RUST_DEBUG` was still turned off because `rust_debug_release` was set to `yes`, not `debug`. Fix this by tweaking how `--enable-rust-debug` works: when it's *not* provided, we default to the `$CFLAGS` detection logic. Otherwise, it overrides it. Closes: #1514 Approved by: cgwalters
2018-08-22 18:32:54 +03:00
if test ${debug_release} = debug; then
libdnf: Update to current master This notably fixes the spam of transaction warnings. Due to a libdnf build system improvement, we no longer need to manually propagate `CFLAGS`. Closes: #499 Approved by: jlebon
2016-10-21 21:39:06 +03:00
cmake_args="-DCMAKE_BUILD_TYPE=Debug"
build-sys: Use python3 for libdnf by default if available Probably at some point libdnf will drop py2 support, but the main reason I'm doing this is avoids a python2 dependency for rpm-ostree for distributions that don't want that. Note of course rpm-ostree itself doesn't use python, libdnf does. And only for the python bindings, which we don't use either. So this is mostly just to DTRT automatically for the libdnf bits; down the line we could probably add a patch to make the python fully conditional. Closes: #1460 Approved by: jlebon
2018-07-16 22:05:37 +03:00
fi
build-sys: Disable zchunk for libdnf if we don't have it Going to update rpm-ostree for RHEL 8.3, we did a huge bump in libdnf which now defaults to enabling zchunk in its build system. We added the infrastructure before to detect things, so propagate that to libdnf.
2020-05-14 03:38:48 +03:00
if test x${have_zchunk} = xno; then
cmake_args="${cmake_args} -DWITH_ZCHUNK:BOOL=0"
fi
build-sys: Hard require Rust As something that manages your base operating system, we care about reliability, predictability, as well as performance and low-level access to native operating system facilities. The C programming language is great for the latter two, but fails at providing a truly memory-safe environment. Rust is fairly unique in providing a language that doesn't carry a runtime, so we can gradually "oxidize" and convert our C code without imposing additional overhead. It's also got a lot of modern design niceties, like not having a null pointer. Let's pull the trigger here and hard require Rust. It's the programming language I personally want to be primarily writing in for years to come. This is also in line with a recent trend of reducing our experimental/optional matrix. Closes: #1509 Approved by: jlebon
2018-08-20 17:40:57 +03:00
export cmake_args
build-sys: Use python3 for libdnf by default if available Probably at some point libdnf will drop py2 support, but the main reason I'm doing this is avoids a python2 dependency for rpm-ostree for distributions that don't want that. Note of course rpm-ostree itself doesn't use python, libdnf does. And only for the python bindings, which we don't use either. So this is mostly just to DTRT automatically for the libdnf bits; down the line we could probably add a patch to make the python fully conditional. Closes: #1460 Approved by: jlebon
2018-07-16 22:05:37 +03:00
Switch to using libhif as a git submodule So I was trying to hack on my host's copy of rpm-ostree inside a pet docker container, but ran into a conflict with libhif since dnf uses it. I think we basically need to *always* build the bundled path, rather than what I'm doing with CAHC and FADC where it's built as a regular RPM. It's not really sustainable right now for us to have both bundled and not-bundled build paths - and we need to support co-installation with dnf. Another major issue is that we want to version lock with libhif - right now our CI and both CAHC/FADC track libhif master, but that means everything breaks if libhif breaks and we don't immediately port. git submodules solve all of these problems - the same as we're doing with libglnx. libglnx is *designed* for use as a git submodule, where as libhif needs to support being both bundled and not-bundled. So we end up with some hacks on our side, but I think it's all not too bad. I've marked build rules with `# bundled libhif` so we know where to find them later when libhif is stable. Closes: #357 Approved by: jlebon
2016-06-29 04:33:02 +03:00
dnl I picked /usr/libexec/rpm-ostree just because we need an
dnl arbitrary path - we don't actually install there.
Makefile-libs.am: Work around `g-ir-scanner` issues with clang Right now there's an issue in Fedora with `g-ir-scanner` picking up `-fstack-clash-protection` from the `sysconfig` Python module and passing it to `clang`, which doesn't understand this flag yet. Just work around this by (1) not even building GIR bindings for our bundled libdnf since there's no need, and (2) overridding the compiler used by `g-ir-scanner` so it's always `gcc`. See: https://github.com/projectatomic/rpm-ostree/pull/1787#issuecomment-473971585 Closes: #1787 Approved by: cgwalters
2019-03-18 19:11:14 +03:00
dnl Use `WITH_GIR=0`; it's our private libdnf bundle and we don't need the bindings.
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
dnl -fPIE for hardening
Update for libhif -> libdnf Still not many PRs outstanding, so it's a good time to take this plunge. Mostly automated via `sed`. Closes: #416 Approved by: Conan-Kudo
2016-08-03 21:30:17 +03:00
(set -euo pipefail; mkdir -p libdnf-build && cd libdnf-build &&
Switch to using libhif as a git submodule So I was trying to hack on my host's copy of rpm-ostree inside a pet docker container, but ran into a conflict with libhif since dnf uses it. I think we basically need to *always* build the bundled path, rather than what I'm doing with CAHC and FADC where it's built as a regular RPM. It's not really sustainable right now for us to have both bundled and not-bundled build paths - and we need to support co-installation with dnf. Another major issue is that we want to version lock with libhif - right now our CI and both CAHC/FADC track libhif master, but that means everything breaks if libhif breaks and we don't immediately port. git submodules solve all of these problems - the same as we're doing with libglnx. libglnx is *designed* for use as a git submodule, where as libhif needs to support being both bundled and not-bundled. So we end up with some hacks on our side, but I think it's all not too bad. I've marked build rules with `# bundled libhif` so we know where to find them later when libhif is stable. Closes: #357 Approved by: jlebon
2016-06-29 04:33:02 +03:00
set -x &&
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
export CXXFLAGS="-fPIE $CXXFLAGS" &&
Switch to using libhif as a git submodule So I was trying to hack on my host's copy of rpm-ostree inside a pet docker container, but ran into a conflict with libhif since dnf uses it. I think we basically need to *always* build the bundled path, rather than what I'm doing with CAHC and FADC where it's built as a regular RPM. It's not really sustainable right now for us to have both bundled and not-bundled build paths - and we need to support co-installation with dnf. Another major issue is that we want to version lock with libhif - right now our CI and both CAHC/FADC track libhif master, but that means everything breaks if libhif breaks and we don't immediately port. git submodules solve all of these problems - the same as we're doing with libglnx. libglnx is *designed* for use as a git submodule, where as libhif needs to support being both bundled and not-bundled. So we end up with some hacks on our side, but I think it's all not too bad. I've marked build rules with `# bundled libhif` so we know where to find them later when libhif is stable. Closes: #357 Approved by: jlebon
2016-06-29 04:33:02 +03:00
cmake \
-DCMAKE_INSTALL_PREFIX:PATH=/usr/libexec/rpm-ostree \
-DINCLUDE_INSTALL_DIR:PATH=/usr/libexec/rpm-ostree/include \
-DLIB_INSTALL_DIR:PATH=/usr/libexec/rpm-ostree \
-DSYSCONF_INSTALL_DIR:PATH=/usr/libexec/rpm-ostree/etc \
-DSHARE_INSTALL_PREFIX:PATH=/usr/libexec/rpm-ostree/share \
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
-DENABLE_STATIC:BOOL=1 \
-DCMAKE_POSITION_INDEPENDENT_CODE=ON \
Switch libdnf to projectatomic branch We previously added a projectatomic/libdnf fork. I just pushed an `rpmostree-branch` to there with one PR on top. This is an unfortunate turn but the C++ thing still needs to be worked out. Obviously we don't want a permanent fork, but I find it hard to justify spending a whole lot of time pitching in to help with the libdnf C++ conversion versus all the other work I could be doing. Update submodule: libdnf Closes: #1114 Approved by: jlebon
2017-11-28 00:54:04 +03:00
-DWITH_SWDB:BOOL=0 \
Update libdnf, disable Python bindings This entirely drops out Sphinx as well as python-devel from our builds, makes builds faster, and silences a lot of warnings too. Update submodule: libdnf Closes: #1480 Approved by: jlebon
2018-07-31 19:12:19 +03:00
-DWITH_BINDINGS:BOOL=0 \
libdnf: Bump and disable html and man pages Skip building man pages and HTML docs for our embedded libdnf to speed up builds. This bump also pulls in a fix to ensure we never try to install src packages from `dnf_context_install()`. See: https://github.com/projectatomic/libdnf/pull/3 Update submodule: libdnf Closes: #1463 Approved by: jlebon
2018-07-17 19:22:26 +03:00
-DWITH_HTML:BOOL=0 \
-DWITH_MAN:BOOL=0 \
Makefile-libs.am: Work around `g-ir-scanner` issues with clang Right now there's an issue in Fedora with `g-ir-scanner` picking up `-fstack-clash-protection` from the `sysconfig` Python module and passing it to `clang`, which doesn't understand this flag yet. Just work around this by (1) not even building GIR bindings for our bundled libdnf since there's no need, and (2) overridding the compiler used by `g-ir-scanner` so it's always `gcc`. See: https://github.com/projectatomic/rpm-ostree/pull/1787#issuecomment-473971585 Closes: #1787 Approved by: cgwalters
2019-03-18 19:11:14 +03:00
-DWITH_GIR:BOOL=0 \
Update for libhif -> libdnf Still not many PRs outstanding, so it's a good time to take this plunge. Mostly automated via `sed`. Closes: #416 Approved by: Conan-Kudo
2016-08-03 21:30:17 +03:00
${cmake_args} ../libdnf) || exit 1
Switch to using libhif as a git submodule So I was trying to hack on my host's copy of rpm-ostree inside a pet docker container, but ran into a conflict with libhif since dnf uses it. I think we basically need to *always* build the bundled path, rather than what I'm doing with CAHC and FADC where it's built as a regular RPM. It's not really sustainable right now for us to have both bundled and not-bundled build paths - and we need to support co-installation with dnf. Another major issue is that we want to version lock with libhif - right now our CI and both CAHC/FADC track libhif master, but that means everything breaks if libhif breaks and we don't immediately port. git submodules solve all of these problems - the same as we're doing with libglnx. libglnx is *designed* for use as a git submodule, where as libhif needs to support being both bundled and not-bundled. So we end up with some hacks on our side, but I think it's all not too bad. I've marked build rules with `# bundled libhif` so we know where to find them later when libhif is stable. Closes: #357 Approved by: jlebon
2016-06-29 04:33:02 +03:00
Initial import from pkgsys-ostree
2013-12-22 04:41:30 +04:00
AC_CONFIG_FILES([
Makefile
Move gtk-doc into api-doc Since that's all it is now, we use mkdocs for the manual.
2016-03-09 19:20:06 +03:00
api-doc/Makefile
Add a public shared library, with "rpm -qa" for commit functionality This will help build release engineering and other types of tools; for example, rather than parsing the output of `db diff`, one should be able to call an API. Initially, this adds the generic infrastructure for a public shared library, with a new function call to do the equivalent of `rpm -qa` on a particular OSTree commit. Closes: https://github.com/projectatomic/rpm-ostree/issues/117 Closes: https://github.com/projectatomic/rpm-ostree/pull/124
2015-03-20 03:45:30 +03:00
src/lib/rpm-ostree-1.pc
lib: Add version macros and version checking function The version checking function in particular is really useful for people doing `from gi.repository import RpmOstree`, which we'd like at least some things like Anaconda and Pungi to do. Closes: #891 Approved by: jlebon
2017-07-21 20:32:58 +03:00
src/lib/rpmostree-version.h
Initial import from pkgsys-ostree
2013-12-22 04:41:30 +04:00
])
AC_OUTPUT
echo "
$PACKAGE $VERSION
Put hawkey stuff behind --enable-patched-hawkey-and-libsolv Right now we depend on two patches.
2014-03-29 06:04:52 +04:00
Implement file triggers (%transfiletriggerin) for layered pkgs File triggers are a post-RHEL7 thing; more information at http://rpm.org/user_doc/file_triggers.html There are two notable users I've been testing this with; `glib2` and `vagrant`. The `vagrant` one is more immediately urgent, since it makes `vagrant-libvirt` work, which I currently rely on for my workstation dev. I've tested things successfully with `vagrant`, and I did verify that we run the `glib2` ones when doing `rpm-ostree ex container`. Long term, more transaction file triggers are likely to live in "base" packages like `glib2`. We don't implement those yet, but extending this to do that shouldn't be too hard. There was *significant* what I'd call reverse engineering of the implementation in librpm. The file triggers code there is spread out and abstracted in a few different places in the code. I found trying to understand what header values were involved to be quite tricky. There are some corner cases like multiple patterns that I *think* this does correctly, but could use more validation. The main question I had was - is it required that the patterns for e.g. `%transfiletriggerin` and `%transfiletriggerun` be identical? Closes: https://github.com/projectatomic/rpm-ostree/issues/648 Closes: #869 Approved by: jlebon
2017-07-07 17:45:10 +03:00
introspection: $found_introspection
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
rojig: ${enable_rojig:-no}
Implement file triggers (%transfiletriggerin) for layered pkgs File triggers are a post-RHEL7 thing; more information at http://rpm.org/user_doc/file_triggers.html There are two notable users I've been testing this with; `glib2` and `vagrant`. The `vagrant` one is more immediately urgent, since it makes `vagrant-libvirt` work, which I currently rely on for my workstation dev. I've tested things successfully with `vagrant`, and I did verify that we run the `glib2` ones when doing `rpm-ostree ex container`. Long term, more transaction file triggers are likely to live in "base" packages like `glib2`. We don't implement those yet, but extending this to do that shouldn't be too hard. There was *significant* what I'd call reverse engineering of the implementation in librpm. The file triggers code there is spread out and abstracted in a few different places in the code. I found trying to understand what header values were involved to be quite tricky. There are some corner cases like multiple patterns that I *think* this does correctly, but could use more validation. The main question I had was - is it required that the patterns for e.g. `%transfiletriggerin` and `%transfiletriggerun` be identical? Closes: https://github.com/projectatomic/rpm-ostree/issues/648 Closes: #869 Approved by: jlebon
2017-07-07 17:45:10 +03:00
gtk-doc: $enable_gtk_doc
rust: Enable lto by default This avoids us leaking all of the Rust symbols as public into our shared library. Came up in team chat since one person tried to copy just `/usr/bin/rpm-ostree` from the dev container into a target and got a linker crash; but really we want to avoid all the duplicated symbols entirely. (And we should investigate cross-language LTO because that's the only way to get full savings)
2020-10-28 23:06:26 +03:00
rust: $rust_debug_release
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: ${cbindgen:-external}
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
sqlite rpmdb default: ${enable_sqlite_rpmdb_default}
Initial import from pkgsys-ostree
2013-12-22 04:41:30 +04:00
"
Reference in New Issue Copy Permalink