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

158 lines
5.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
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
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
dnl 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])
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
dnl These are the dependencies of the public librpmostree-1.0.0 shared library
PKG_CHECK_MODULES(PKGDEP_LIBRPMOSTREE, [gio-unix-2.0 >= 2.50.0 json-glib-1.0 ostree-1 >= 2020.7 rpm])
dnl And these additional ones are used by for the rpmostreeinternals C/C++ library
PKG_CHECK_MODULES(PKGDEP_RPMOSTREE, [polkit-gobject-1 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
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])])
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
build-sys: Add --enable-werror, rework compiler flags So...at some point we somehow lost `-Wall` in our default compiler flags which means we were missing some potentially important warnings. And we used to have `-Werror` on in CI which combined with the above was strongly opinionated about not landing warnings in git master. Our default stance here remains the same; we have an opinionated set of `-Werror=` that applies in *all* configurations. However that set moves into Automake - I don't think we need to do compiler version detection anymore, we can assume a modern compiler. We also add back in `-Wall` by default now. Further in CI, add `-Werror`. The implementation here is in our buildsystem rather than `export CXXFLAGS=-Werror` because unfortunately we have to fix things in libdnf too, and I don't want to block entirely on that.
2021-02-08 21:22:34 +03:00
AC_ARG_ENABLE(werror,
AS_HELP_STRING([--enable-werror],
[Enable -Werror for C/C++ (default: no)]),,
[enable_werror=no])
AM_CONDITIONAL(BUILDOPT_WERROR, [test x$enable_werror != xno])
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])
])
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