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

151 lines
5.2 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])
Release 2021.5 New release `2021.5`.
2021-05-11 16:56:26 +03:00
m4_define([release_version], [5])
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
Add --enable-sanitizers (not on by default yet) This way we at least get unit test coverage (which... our unit test coverage doesn't do much because our main code paths require privileges or virt). One main blocker to this is that rustc doesn't expose first-class support for this yet: https://github.com/rust-lang/rust/issues/39699 At a practical level this works when building in release mode but fails with `cargo test` for some reason; linker arguments being pruned? Not sure. So I was able to use this when composing to find a bug, but then for some other reason the client side apparently infinite loops inside libsolv. So we're not enabling this yet for those reasons, but let's land the build infrastructure now. ``` (lldb) thread backtrace * thread #4, name = 'pool-/usr/bin/r' * frame #0: 0x00007fd61b97200f libc.so.6`__memcpy_sse2_unaligned_erms + 623 frame #1: 0x00007fd61cbc88e6 libasan.so.6`__asan::asan_realloc(void*, unsigned long, __sanitizer::BufferedStackTrace*) + 214 frame #2: 0x00007fd61cc4b725 libasan.so.6`__interceptor_realloc + 245 frame #3: 0x00007fd61baec43e libsolv.so.1`solv_realloc + 30 frame #4: 0x00007fd61baf0414 libsolv.so.1`repodata_add_dirstr + 276 frame #5: 0x00007fd61bb6f755 libsolvext.so.1`end_element + 53 frame #6: 0x00007fd61b05855d libxml2.so.2`xmlParseEndTag1.constprop.0 + 317 frame #7: 0x00007fd61b063548 libxml2.so.2`xmlParseTryOrFinish.isra.0 + 888 frame #8: 0x00007fd61af7ed20 libxml2.so.2`xmlParseChunk + 560 frame #9: 0x00007fd61bb727e7 libsolvext.so.1`solv_xmlparser_parse + 183 frame #10: 0x00007fd61bb5ea0e libsolvext.so.1`repo_add_rpmmd + 254 frame #11: 0x000055a4fce7a5f5 rpm-ostree`::load_filelists_cb(repo=<unavailable>, fp=<unavailable>) at dnf-sack.cpp:444:23 frame #12: 0x000055a4fce7cad6 rpm-ostree`load_ext(_DnfSack*, libdnf::Repo*, _hy_repo_repodata, char const*, char const*, int (*)(s_Repo*, _IO_FILE*), _GError**) at dnf-sack.cpp:430:13 frame #13: 0x000055a4fce7df60 rpm-ostree`dnf_sack_load_repo at dnf-sack.cpp:1789:26 frame #14: 0x000055a4fce7eee9 rpm-ostree`dnf_sack_add_repo at dnf-sack.cpp:2217:28 frame #15: 0x000055a4fce7f0fb rpm-ostree`dnf_sack_add_repos at dnf-sack.cpp:2271:32 frame #16: 0x000055a4fce870ee rpm-ostree`dnf_context_setup_sack_with_flags at dnf-context.cpp:1796:29 frame #17: 0x000055a4fcdf757f rpm-ostree`rpmostree_context_download_metadata at rpmostree-core.cxx:1206:44 frame #18: 0x000055a4fcdf95c3 rpm-ostree`rpmostree_context_prepare at rpmostree-core.cxx:2001:48 frame #19: 0x000055a4fce54ab7 rpm-ostree`rpmostree_sysroot_upgrader_prep_layering at rpmostree-sysroot-upgrader.cxx:1018:38 frame #20: 0x000055a4fcdcb143 rpm-ostree`deploy_transaction_execute(_RpmostreedTransaction*, _GCancellable*, _GError**) at rpmostreed-transaction-types.cxx:1445:49 frame #21: 0x000055a4fcdba4cd rpm-ostree`transaction_execute_thread(_GTask*, void*, void*, _GCancellable*) at rpmostreed-transaction.cxx:340:34 frame #22: 0x00007fd61c58f7e2 libgio-2.0.so.0`g_task_thread_pool_thread + 114 frame #23: 0x00007fd61c3d7e54 libglib-2.0.so.0`g_thread_pool_thread_proxy.lto_priv.0 + 116 frame #24: 0x00007fd61c3d52b2 libglib-2.0.so.0`g_thread_proxy + 82 frame #25: 0x00007fd61b8af3f9 libpthread.so.0`start_thread + 233 frame #26: 0x00007fd61b9c9903 libc.so.6`__clone + 67 (lldb) ```
2021-02-03 00:54:38 +03:00
AC_ARG_ENABLE(sanitizers,
AS_HELP_STRING([--enable-sanitizers],
[Enable ASAN and UBSAN (default: no)]),,
[enable_sanitizers=no])
AM_CONDITIONAL(BUILDOPT_ASAN, [test x$enable_sanitizers != xno])
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
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
Require ostree v2021.2, use ostree-ext crate This uses the ostree and ostree-ext crates from git as a demo/WIP for https://mail.gnome.org/archives/ostree-list/2021-April/msg00000.html
2021-04-05 23:15:54 +03:00
PKG_CHECK_MODULES(PKGDEP_LIBRPMOSTREE, [gio-unix-2.0 >= 2.50.0 json-glib-1.0 ostree-1 >= 2021.2 rpm])
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 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])])
lib: temporarily fork rpmver logic This adds an internal temporary copy of the rpm version comparison logic from librpmio (LGPL). It allows relaxing the minimum library version to >= 4.14.
2021-05-31 13:15:55 +03:00
# rpmver is available in rpm >= 4.16, el8 is still on 4.14
AC_SEARCH_LIBS([rpmverCmp], [rpm],
AC_DEFINE([BUILDOPT_HAVE_RPMVER], 1, [Whether rpmver API is available in librpmio]),
AC_DEFINE([BUILDOPT_HAVE_RPMVER], 0, [Whether rpmver API is available in librpmio])
)
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
ci: Rework build/test dependency install Now that `ci/installdeps.sh` gracefully exits if run as non-root, we can fold the cargo bits into the our build scripts and avoid invoking both of them. However, now we need to split test deps to separate file because we won't have `cargo` in the main cosa pod. This also fixes a FIXME. Steal the `grep` invocation from cosa and make it a declarative text file so we can have comments per package etc.
2021-02-16 21:15:21 +03:00
dnl See comment in installdeps.sh
Remove cbindgen We have fully transitioned to cxx-rs! This drops a lot of now dead code; only one binding system to think about generating source code. For example, a notable advantage of cxx-rs is it doesn't scan the whole source code, so running `make` doesn't spew errors from cbindgen not understanding bits.
2021-03-03 04:12:00 +03:00
AM_CONDITIONAL(BUILDOPT_PREBUILT_BINDINGS, [test -f rpmostree-cxxrs-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
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
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-sanitizers (not on by default yet) This way we at least get unit test coverage (which... our unit test coverage doesn't do much because our main code paths require privileges or virt). One main blocker to this is that rustc doesn't expose first-class support for this yet: https://github.com/rust-lang/rust/issues/39699 At a practical level this works when building in release mode but fails with `cargo test` for some reason; linker arguments being pruned? Not sure. So I was able to use this when composing to find a bug, but then for some other reason the client side apparently infinite loops inside libsolv. So we're not enabling this yet for those reasons, but let's land the build infrastructure now. ``` (lldb) thread backtrace * thread #4, name = 'pool-/usr/bin/r' * frame #0: 0x00007fd61b97200f libc.so.6`__memcpy_sse2_unaligned_erms + 623 frame #1: 0x00007fd61cbc88e6 libasan.so.6`__asan::asan_realloc(void*, unsigned long, __sanitizer::BufferedStackTrace*) + 214 frame #2: 0x00007fd61cc4b725 libasan.so.6`__interceptor_realloc + 245 frame #3: 0x00007fd61baec43e libsolv.so.1`solv_realloc + 30 frame #4: 0x00007fd61baf0414 libsolv.so.1`repodata_add_dirstr + 276 frame #5: 0x00007fd61bb6f755 libsolvext.so.1`end_element + 53 frame #6: 0x00007fd61b05855d libxml2.so.2`xmlParseEndTag1.constprop.0 + 317 frame #7: 0x00007fd61b063548 libxml2.so.2`xmlParseTryOrFinish.isra.0 + 888 frame #8: 0x00007fd61af7ed20 libxml2.so.2`xmlParseChunk + 560 frame #9: 0x00007fd61bb727e7 libsolvext.so.1`solv_xmlparser_parse + 183 frame #10: 0x00007fd61bb5ea0e libsolvext.so.1`repo_add_rpmmd + 254 frame #11: 0x000055a4fce7a5f5 rpm-ostree`::load_filelists_cb(repo=<unavailable>, fp=<unavailable>) at dnf-sack.cpp:444:23 frame #12: 0x000055a4fce7cad6 rpm-ostree`load_ext(_DnfSack*, libdnf::Repo*, _hy_repo_repodata, char const*, char const*, int (*)(s_Repo*, _IO_FILE*), _GError**) at dnf-sack.cpp:430:13 frame #13: 0x000055a4fce7df60 rpm-ostree`dnf_sack_load_repo at dnf-sack.cpp:1789:26 frame #14: 0x000055a4fce7eee9 rpm-ostree`dnf_sack_add_repo at dnf-sack.cpp:2217:28 frame #15: 0x000055a4fce7f0fb rpm-ostree`dnf_sack_add_repos at dnf-sack.cpp:2271:32 frame #16: 0x000055a4fce870ee rpm-ostree`dnf_context_setup_sack_with_flags at dnf-context.cpp:1796:29 frame #17: 0x000055a4fcdf757f rpm-ostree`rpmostree_context_download_metadata at rpmostree-core.cxx:1206:44 frame #18: 0x000055a4fcdf95c3 rpm-ostree`rpmostree_context_prepare at rpmostree-core.cxx:2001:48 frame #19: 0x000055a4fce54ab7 rpm-ostree`rpmostree_sysroot_upgrader_prep_layering at rpmostree-sysroot-upgrader.cxx:1018:38 frame #20: 0x000055a4fcdcb143 rpm-ostree`deploy_transaction_execute(_RpmostreedTransaction*, _GCancellable*, _GError**) at rpmostreed-transaction-types.cxx:1445:49 frame #21: 0x000055a4fcdba4cd rpm-ostree`transaction_execute_thread(_GTask*, void*, void*, _GCancellable*) at rpmostreed-transaction.cxx:340:34 frame #22: 0x00007fd61c58f7e2 libgio-2.0.so.0`g_task_thread_pool_thread + 114 frame #23: 0x00007fd61c3d7e54 libglib-2.0.so.0`g_thread_pool_thread_proxy.lto_priv.0 + 116 frame #24: 0x00007fd61c3d52b2 libglib-2.0.so.0`g_thread_proxy + 82 frame #25: 0x00007fd61b8af3f9 libpthread.so.0`start_thread + 233 frame #26: 0x00007fd61b9c9903 libc.so.6`__clone + 67 (lldb) ```
2021-02-03 00:54:38 +03:00
ASAN + UBSAN: ${enable_sanitizers:-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
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