mirror-cockpit-project-cockpit/autogen.sh

#!/bin/sh

set -eu

srcdir="${0%/*}"

(
    cd "${srcdir}"
    echo "m4_define(VERSION_NUMBER, [$(git describe --tags --abbrev=0)+git])" > version.m4
    autoreconf -i --warnings obsolete
)

[ -n "${NOCONFIGURE:-}" ] && exit

case "${1:-}" in
    rpm)
        # configure with the same flags as when building an RPM
        exec rpmbuild -D '_topdir tmp/rpmbuild' -D 'make_build #' \
            --build-in-place -bc tools/cockpit.spec ;;

    *)
        exec "${srcdir}/configure" "$@" ;;
esac
Initial commit 2013-11-01 09:42:29 -08:00			`#!/bin/sh`

autogen.sh: minimalistic rewrite Take the axe to autogen.sh and replace it with a clean minimalistic rewrite. 2021-06-30 01:10:27 -08:00			`set -eu`
Initial commit 2013-11-01 09:42:29 -08:00
scripts: stop abusing `realpath -m` Many of our scripts follow the pattern of using something like cd "$(realpath -m $0/../../..)" in order to change to the top source directory. The idea of applying `..` to a regular file (`$0`, the path to the script itself) is a bit weird, but the `realpath -m` (`--canonicalize-missing`) flag allows that by ignoring the content of the filesystem. In effect, the first `..` removes the basename, and then the remaining `../..` express the location of the top directory relative to the directory containing the script. Experiments building Cockpit in container environments have shown that `realpath -m` is non-POSIX. There's an alternative, however, and it has the advantage of not using any external tools at all: we can do the first step of removing the basename by using shell parameter expansion: `"${0%/}"`. From there, we can just append the correct number of `../..` to get the desired path: cd "${0%/}/../.." Update this pattern (and similar) in all the scripts which use it. 2022-05-01 23:16:52 -08:00			`srcdir="${0%/*}"`
Initial commit 2013-11-01 09:42:29 -08:00
build: change approach to versioning Currently, we choose the version number that we use at the time that ./autogen.sh is first run. That means that if you configure your tree and hack on it for a while, making commits as you go, the overly-specific version number will soon be out of date. This version number is the number used when building tarballs for testing. Even switching to old branches on previous versions can result in the version number not being updated. Let's move to automake's suggested approach[1] to dynamic versioning by introducing a `version.m4` file. We write that file from two places: - `./autogen.sh` writes an approximate version number (the last release) appended by +git (eg. "270+git") - from `make dist` we write the value we find in `$(VERSION)` and call autoreconf to update the configure script accordingly The expectation is now that anyone who calls `make dist` should specify the VERSION explicitly. That's two places: - from `tools/make-dist` we specify the full `git describe` style version - from the release workflow we specify the tag name Since the only thing that uses `make dump-dist` anymore is `tools/make-dist`, and since it now provides its own version number, we can drop the rule and print the filename directly. Since we move to `version.m4`-style versioning, our tarballs will no longer contain the `.tarball` file. Finally, since we're going to end up having more tarballs created, with various version numbers, add `cockpit-*.tar.xz` to `CLEANFILES` to help keep things under control. [1] https://www.gnu.org/software/automake/manual/html_node/Rebuilding.html 2022-06-01 00:03:30 -08:00			`(`
			`cd "${srcdir}"`
			`echo "m4_define(VERSION_NUMBER, [$(git describe --tags --abbrev=0)+git])" > version.m4`
autogen: Copy automake tools Building the dist tarball in the current Fedora 37 cockpit/tasks container now fails when running as user podman container, when using systemd-homed: cp: failed to preserve ownership for 'cockpit-279.39.gb4b41375f/tools/compile': Value too large for defined data type This was due to a change in systemd 251 with mapped user IDs[1][2]. Work around this by copying the files instead of symlinking them. That is the default behaviour anyway, and does not hurt much: git trees are regularly cleaned by developers anyway, and dist tarballs contain a copy either way. [1] https://github.com/systemd/systemd/blob/1d679b208d982bd5b8ba893981774cac5959b4b4/NEWS#L789 [2] https://bugzilla.redhat.com/show_bug.cgi?id=2144558 2022-11-15 05:32:55 -09:00			`autoreconf -i --warnings obsolete`
build: change approach to versioning Currently, we choose the version number that we use at the time that ./autogen.sh is first run. That means that if you configure your tree and hack on it for a while, making commits as you go, the overly-specific version number will soon be out of date. This version number is the number used when building tarballs for testing. Even switching to old branches on previous versions can result in the version number not being updated. Let's move to automake's suggested approach[1] to dynamic versioning by introducing a `version.m4` file. We write that file from two places: - `./autogen.sh` writes an approximate version number (the last release) appended by +git (eg. "270+git") - from `make dist` we write the value we find in `$(VERSION)` and call autoreconf to update the configure script accordingly The expectation is now that anyone who calls `make dist` should specify the VERSION explicitly. That's two places: - from `tools/make-dist` we specify the full `git describe` style version - from the release workflow we specify the tag name Since the only thing that uses `make dump-dist` anymore is `tools/make-dist`, and since it now provides its own version number, we can drop the rule and print the filename directly. Since we move to `version.m4`-style versioning, our tarballs will no longer contain the `.tarball` file. Finally, since we're going to end up having more tarballs created, with various version numbers, add `cockpit-*.tar.xz` to `CLEANFILES` to help keep things under control. [1] https://www.gnu.org/software/automake/manual/html_node/Rebuilding.html 2022-06-01 00:03:30 -08:00			`)`

autogen.sh: add 'rpm' option When run as `./autogen.sh rpm` then configure the package in exactly the same way as it would be configured by RPM for a build on this system. 2022-01-24 02:15:10 -09:00			`[ -n "${NOCONFIGURE:-}" ] && exit`
Initial commit 2013-11-01 09:42:29 -08:00
autogen.sh: add 'rpm' option When run as `./autogen.sh rpm` then configure the package in exactly the same way as it would be configured by RPM for a build on this system. 2022-01-24 02:15:10 -09:00			`case "${1:-}" in`
			`rpm)`
			`# configure with the same flags as when building an RPM`
			`exec rpmbuild -D '_topdir tmp/rpmbuild' -D 'make_build #' \`
tools: Drop create-spec Keep `Version: 0` in the spec file. This works fine with `autogen rpm`, `dnf builddep, and Packit. It was the last macro, so now it's a real working .spec. This avoids having to invoke this script all the time. This simplifies our packit config a bit and stops swimming against the stream. The only place where we want a real version is `make dist`, so that built RPMs have a correct version. Rework the rule to modify the file in-place in distdir. Unfortunately this uncovers another packit bug: If the .spec file is not in the same directory as the tarball, `packit srpm` gets upset: <https://github.com/packit/packit/issues/1621>. Work around that by copying the spec to the root directory, and pointing to it. 2022-06-14 02:22:40 -08:00			`--build-in-place -bc tools/cockpit.spec ;;`
autogen.sh: add 'rpm' option When run as `./autogen.sh rpm` then configure the package in exactly the same way as it would be configured by RPM for a build on this system. 2022-01-24 02:15:10 -09:00
			`*)`
			`exec "${srcdir}/configure" "$@" ;;`
			`esac`