quine-global-labs/mirror-cockpit-project-cockpit
1
0
Fork 0
mirror of https://github.com/cockpit-project/cockpit.git synced 2026-11-03 21:49:50 -09:00
Code Issues Projects Releases Packages Wiki Activity
mirror-cockpit-project-cockpit/Makefile.am

189 lines
6.6 KiB
Text
Raw Normal View History

Initial commit
2013-11-01 09:42:29 -08:00
NULL =
build: stop generating valgrind-suppressions Valgrind takes multiple --suppressions arguments, so use that instead.
2022-02-25 06:44:52 -09:00
CLEANFILES =
build: lift docs rules out of toplevel Makefile This `if ENABLE_DOC` soup has no business being in the toplevel Makefile. Its reasons for being there are somewhat complicated, and have to do with automake's distaste for ::-style rules mixed with conditionals. We've often written rules like some-hook:: if ENABLE_DOC do_stuff endif for this reason. Invent a new approach that involves unconditionally adding a single dependency-only line for each hook, having it depend on a per-hook _TARGETS variable. The individual targets can now easily conditionally add themselves to the variable without triggering automake's wrath, which allows for things to be written much more cleanly. Neaten up the docs stuff accordingly, and move it to the makefile in doc/guide. Also use the dist_ trick (instead of EXTRA_DIST) to get files in the tarball regardless of which conditions are enabled.
2022-03-09 01:12:42 -09:00
dist_noinst_DATA =
build: massive overhaul of build system Clean up the pkg-config and some `--enable-` flags usage in configure.ac. Stop defining AC_SUBST rules like COCKPIT_WS_CFLAGS and just let the pkg-config results go through. The Makefiles can decide for themselves which bits they want to use for each component. Create a new library, libcockpit-test.a, from the files in src/testlib/. This library gets linked from all test programs. Adjust all of the Makefiles in src/ to these two changes, and perform general cleanup. One major goal of this cleanup is to make standalone segments of the file for separate build targets. For example, adding a new unit test shouldn't involve adding it to a list in one place and then defining variables in another: this should all be done in one set of adjacent lines.
2022-03-06 22:50:12 -09:00
man_MANS =
noinst_DATA =
noinst_LIBRARIES =
Initial commit
2013-11-01 09:42:29 -08:00
noinst_PROGRAMS =
build: allow external Python to be used
2025-02-03 22:44:07 -09:00
PYTHON3 ?= python3
Initial commit
2013-11-01 09:42:29 -08:00
build: Move package-lock.json and FORCE rules to top-level Makefile `FORCE` is also a dependency of the `version.m4` target in the top-level Makefile.am, so it's confusing to only define it in the pkg/ subdirectory. Now it's only used in the top-level Makefile.am. `package-lock.json` is also a dependeny of po/Makefile.am, so it should also be shared and move to the top-level file. Consistently refer to it via `$(srcdir). `node_modules/*` also only gets referred to in the top-level Makefile.am for the EXTRA_DIST of the integration test dependencies. Move it next to that.
2023-03-20 21:42:53 -08:00
# See https://www.gnu.org/software/make/manual/html_node/Force-Targets.html
FORCE:
# -----------------------------------------------------------------------------
# node_modules/package-lock.json dependency
V_NODE_MODULES = $(V_NODE_MODULES_$(V))
V_NODE_MODULES_ = $(V_NODE_MODULES_$(AM_DEFAULT_VERBOSITY))
V_NODE_MODULES_0 = @V=0
# We want tools/node-modules to run every time package-lock.json is requested
$(srcdir)/package-lock.json: FORCE
$(V_NODE_MODULES) $(srcdir)/tools/node-modules make_package_lock_json
Makefile.am: group all dist-related stuff Move everything to do with `make dist` to a section at the top.
2022-03-09 02:34:18 -09:00
# -----------------------------------------------------------------------------
# make dist
users: Migrate to webpack Reviewed-by: Lars Uebernickel <lars@uebernic.de>
2016-07-05 07:04:57 -08:00
REUSE: Add missing licenses The bridge, and also some parts of pkg/lib/ are GPL-3.0-and-later licensed, not LGPL-2.1. At some point we should clean this up, but for now accept the status quo and ship the GPL 3 text. The four patternfly react-templates copies in pkg/lib are MIT licensed. Rename/add them to "LICENSES/<spdx>.txt" as recommended by https://reuse.software/spec-2.0/ Note: pkg/storaged/icons/gnome-icons.jsx is CC-BY-SA-3.0 licensed (or LGPL-3.0). This does not have a canonical plaintext format, just the webpage. So don't copy that, retaining the current license header in that file is good enough. Adjust the .spec accordingly.
2026-02-01 03:40:49 -09:00
EXTRA_DIST = README.md LICENSES/BSD-3-Clause.txt LICENSES/GPL-3.0.txt LICENSES/LGPL-2.1.txt LICENSES/MIT.txt
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
CLEANFILES += cockpit-*.tar.xz
Distribute dependencies and their licenses Distribute devel dependencies in the tarball, and include licenses appropriately. To do this we need to make two changes: * Use xz to compress the tarball, so that it stays relatively small * Use the tar-pax format because file names get very long. Closes #3436 Reviewed-by: Dominik Perpeet <dperpeet@redhat.com>
2016-01-07 11:56:05 -09:00
tools: Declare bundled NPM dependencies in spec file Fixes https://bugzilla.redhat.com/show_bug.cgi?id=2180520 We need to get a bit creative for packit: It needs the spec as first thing, so build it manually. Share the code in a separate tools/fix-spec for that. Drop the obsolete hack for https://github.com/packit/packit/issues/1560 as that was fixed in packit a while ago.
2023-04-03 03:28:37 -08:00
# We override distdir as we want to dist some git-tracked files and dist/ without explicitly listing.
# The spec also gets patched to declare bundled NPM dependencies.
build: drop tar tricks in dist-hook We use a dist-hook combined with tar for some fairly complicated reasons, constituting one of the most non-obvious corners of the build system. The main reasons for that are: 1) directly adding a list of files in git to EXTRA_DIST is not something that can be done reasonably in make syntax, and particularly when we also need it to work when building from tar 2) (and this is complicated) we support typing `make dist` directly after configuring the package in order to get a .tar release, containing the files built by webpack (which will be implicitly built as a part of `make dist`). We know what files to ship because `webpack-make` writes a set of `Makefile.deps` files, setting the `WEBPACK_INPUTS` and `WEBPACK_OUTPUTS` variables. At the time of the first `make dist` invocation on the freshly-configured project, we immediately call `make distdir-am` which is what invokes webpack-make. However: this invocation of make doesn't get a chance to include the Makefiles that weren't present at the time it was invoked, and as a result, doesn't have access to the final values of `WEBPACK_INPUTS` and `WEBPACK_OUTPUTS`. We've solved this by using `dist-hook` (which gets a fresh recursive make invocation, and a new chance to read the Makefiles.deps). 3) we want to make some minor adjustments to the distdir (adding a .tarball file, adjusting timestamps, etc). Our use of tar is pretty evil here, though, and it breaks badly when combined with out-of-tree builds. It turns out that automake has quite some logic for dealing with VPATH demangling, if only we can get the files that we want to ship into `EXTRA_DIST` at the time of the `make distdir-am` invocation. We achieve this by using our (already existing) `distdir:` target override to gain more control over the `make distdir-am` invocation. The three points above are addressed, as follows: 1) If we're in a git tree, we create (or update) a .committed_files file on `make dist` and pass its contents to be added to `EXTRA_DIST` in the `make distdir-am` invocation. We add this file itself to the dist, avoiding the need to use `find` in the "non-git" case. 2) By adding `$(DISTFILES)` as a dependency of the `distdir:` target, we can be sure our webpack (and other things in parallel) will be built by the time we do the recursive `make distdir-am` invocation. This specifically means that the Makfefile.deps will be available to be included, allowing `WEBPACK_INPUTS` and `WEBPACK_OUTPUTS` to be added to `EXTRA_DIST` in the usual way. 3) We can make our minor adjustments to the distdir directly from the `distdir:` target, after the `make distdir-am` invocation. In addition to working with out-of-tree builds, the new approach is, to my eye, much easier to understand in depth.
2022-03-09 02:38:50 -09:00
EXTRA_DIST += $(EXTRA_FILES)
distdir: $(DISTFILES)
@if [ -e '$(srcdir)/.git' ]; then \
build: Put .cockpit-ci into source tarballs So that test/browser/browser.sh can find it when it runs from a source tarball during Fedora package gating.
2024-03-27 05:15:43 -08:00
git -C '$(srcdir)' ls-files -x test/reference .fmf .cockpit-ci plans pkg test tools > .extra_dist.tmp && \
build: drop tar tricks in dist-hook We use a dist-hook combined with tar for some fairly complicated reasons, constituting one of the most non-obvious corners of the build system. The main reasons for that are: 1) directly adding a list of files in git to EXTRA_DIST is not something that can be done reasonably in make syntax, and particularly when we also need it to work when building from tar 2) (and this is complicated) we support typing `make dist` directly after configuring the package in order to get a .tar release, containing the files built by webpack (which will be implicitly built as a part of `make dist`). We know what files to ship because `webpack-make` writes a set of `Makefile.deps` files, setting the `WEBPACK_INPUTS` and `WEBPACK_OUTPUTS` variables. At the time of the first `make dist` invocation on the freshly-configured project, we immediately call `make distdir-am` which is what invokes webpack-make. However: this invocation of make doesn't get a chance to include the Makefiles that weren't present at the time it was invoked, and as a result, doesn't have access to the final values of `WEBPACK_INPUTS` and `WEBPACK_OUTPUTS`. We've solved this by using `dist-hook` (which gets a fresh recursive make invocation, and a new chance to read the Makefiles.deps). 3) we want to make some minor adjustments to the distdir (adding a .tarball file, adjusting timestamps, etc). Our use of tar is pretty evil here, though, and it breaks badly when combined with out-of-tree builds. It turns out that automake has quite some logic for dealing with VPATH demangling, if only we can get the files that we want to ship into `EXTRA_DIST` at the time of the `make distdir-am` invocation. We achieve this by using our (already existing) `distdir:` target override to gain more control over the `make distdir-am` invocation. The three points above are addressed, as follows: 1) If we're in a git tree, we create (or update) a .committed_files file on `make dist` and pass its contents to be added to `EXTRA_DIST` in the `make distdir-am` invocation. We add this file itself to the dist, avoiding the need to use `find` in the "non-git" case. 2) By adding `$(DISTFILES)` as a dependency of the `distdir:` target, we can be sure our webpack (and other things in parallel) will be built by the time we do the recursive `make distdir-am` invocation. This specifically means that the Makfefile.deps will be available to be included, allowing `WEBPACK_INPUTS` and `WEBPACK_OUTPUTS` to be added to `EXTRA_DIST` in the usual way. 3) We can make our minor adjustments to the distdir directly from the `distdir:` target, after the `make distdir-am` invocation. In addition to working with out-of-tree builds, the new approach is, to my eye, much easier to understand in depth.
2022-03-09 02:38:50 -09:00
mv .extra_dist.tmp '$(srcdir)/.extra_dist'; fi
$(MAKE) $(AM_MAKEFLAGS) distdir-am EXTRA_FILES="$$(tr '\n' ' ' < $(srcdir)/.extra_dist) .extra_dist"
build: rip out automated version history Automatically checking all of the tags in order to construct our version history has always been a bit gross. It means that what lands in the release tarball is determined by more than just the current commit. On top of that, the script to do this nasty bit of work just produced an output which failed to validate, owing to the recent out-of-sequence release of 264.2. Version history really ought to be tracked downstream, so let's rip all of this out and replace it with a very simple approach to writing a single release line into the file. This is the minimum required for the file to validate. Any additional history can be handled downstream (manually, for the time being).
2022-09-23 00:32:59 -08:00
sed -i "s/[@]VERSION@/$(VERSION)/" "$(distdir)/src/client/org.cockpit_project.CockpitClient.metainfo.xml"
tools: Declare bundled NPM dependencies in spec file Fixes https://bugzilla.redhat.com/show_bug.cgi?id=2180520 We need to get a bit creative for packit: It needs the spec as first thing, so build it manually. Share the code in a separate tools/fix-spec for that. Drop the obsolete hack for https://github.com/packit/packit/issues/1560 as that was fixed in packit a while ago.
2023-04-03 03:28:37 -08:00
$(srcdir)/tools/fix-spec $(distdir)/tools/cockpit.spec $(VERSION)
tools: Drop templating for Arch and Debian packaging The previous commit dropped the templating for .spec files. For symmetry, do the same to the other packaging files.
2022-06-15 05:29:26 -08:00
sed -i "/^pkgver=/ s/0/$(VERSION)/" "$(distdir)/tools/arch/PKGBUILD"
sed -i "1 s/0/$(VERSION)/" "$(distdir)/tools/debian/changelog"
build: Only include actually bundled npm modules into the spec Our package.json's `dependencies` has transitive/optional dependencies which don't actually end up in the bundle, e.g. `argparse`, `attr-accept`, or `js-tokens`; or `react-dropzone` which is a `@patternfly/react-table` dependency, but not actually used in cockpit. The next commit will aggravate this further. So make the computation of the `Provides: bundled(npm(..))` lines more precise: Ask esbuild about which modules it actually included, which it tells us via the "metafile". Change build.js to always output that (drop the `--metafile` option), compute a ./runtime-npm-modules.txt list, and use that to build the spec file. Ported from https://github.com/cockpit-project/cockpit-files/commit/e15a518fddad1
2025-11-18 10:42:57 -09:00
cp -r "$(srcdir)/dist" "$(srcdir)/runtime-npm-modules.txt" "$(distdir)"
build: fix out-of-tree `make dist` We have two tools invocations in the dist-hook which don't properly run the tool from $(srcdir). Fix that.
2022-03-09 02:41:15 -09:00
$(srcdir)/tools/adjust-distdir-timestamps "$(distdir)"
make-dist: add a bit more 'pretty' output Add automake "silent rules"-style messages for autogen and configure invocations from tools/make-dist. Add an output from disthook in Makefile.am for preparing the tarball.
2022-03-11 00:03:50 -09:00
@echo ' DIST $(DIST_ARCHIVES)'
Integrate webpack into the make process Reviewed-by: Lars Uebernickel <lars@uebernic.de>
2016-07-01 15:41:25 -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
# Needed to ensure the tarball is correct for $(VERSION) override
build: include Python files in the "dist" tarball Add `tools/dist-setuptools`: a new command to copy all of the source files that setuptools would include in its sdist to a different directory. We use that during `make dist` to make sure those files end up in the primary automake dist tarball. This lets the Python build system decide what gets included. We also take the chance to tweak the version number in `_version.py` in the distdir to be equal to the version number of the main package. Note: our first attempts here involved building and unpacking an sdist but that failed because setuptools tries to write to the source directory, which automake (particularly, `make distcheck`) dislikes. Finally, we have to adjust our debian packaging a bit to suppress a false-positive lintian warning.
2023-04-27 09:51:45 -08:00
dist-hook: $(distdir)/src/cockpit/_version.py
$(distdir)/src/cockpit/_version.py: FORCE
build: allow external Python to be used
2025-02-03 22:44:07 -09:00
$(PYTHON3) '$(srcdir)'/src/build_backend.py --copy '$(srcdir)' '$(distdir)'
build: include Python files in the "dist" tarball Add `tools/dist-setuptools`: a new command to copy all of the source files that setuptools would include in its sdist to a different directory. We use that during `make dist` to make sure those files end up in the primary automake dist tarball. This lets the Python build system decide what gets included. We also take the chance to tweak the version number in `_version.py` in the distdir to be equal to the version number of the main package. Note: our first attempts here involved building and unpacking an sdist but that failed because setuptools tries to write to the source directory, which automake (particularly, `make distcheck`) dislikes. Finally, we have to adjust our debian packaging a bit to suppress a false-positive lintian warning.
2023-04-27 09:51:45 -08:00
@rm -f $(distdir)/src/cockpit/_version.py
$(AM_V_GEN) echo "__version__ = '$(VERSION)'" > $@
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
$(distdir)/version.m4: FORCE
@rm -f $(distdir)/version.m4
$(AM_V_GEN) echo 'm4_define(VERSION_NUMBER, [$(VERSION)])' > $@
build: Drop autom4te.cache from release tarballs They don't belong there and cause ugly warnings when building the Debian source package. This was unintended fallout from commit e2f2d830.
2023-01-07 07:03:17 -09:00
# be careful not to include autotools cache into dist tarballs
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
dist-hook: $(distdir)/configure
$(distdir)/configure: $(distdir)/version.m4
@rm -f $(distdir)/configure
$(AM_V_GEN) autoreconf $(distdir)
build: Drop autom4te.cache from release tarballs They don't belong there and cause ugly warnings when building the Debian source package. This was unintended fallout from commit e2f2d830.
2023-01-07 07:03:17 -09:00
@rm -r $(distdir)/autom4te.cache
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
build: turn packaging files into proper rules Move all of our packaging-related files that we create at `make dist` out of `dist-hook` and into their own rules, with nice `$(AM_V_GEN)` output. Turn `dist-hook` into a pure list of dependencies on those files. Move the remaining rules into the main `distdir` target, which we were already overriding anyway. These will be dealt with in following commits.
2022-05-24 03:44:24 -08:00
# Various downstream packaging assets
build: Create node runtime tarball as part of "make dist" The next commit we will require the `node-modules runtime-tar` tarball for building the debian/copyright file. Similarly to what cockpit-{podman,files} already do, change `make dist` to produce the node tarball as well, instead of making this a separate action. In tools/release, wrap the two generated tarballs into an outer `tar` so that we can squeeze both through the build container's stdout.
2025-12-04 12:30:46 -09:00
build: Fix inconsistent NODE_CACHE path We want NODE_CACHE to be a built file in the build dir. So declare that properly and use it at face value, instead of mangling the path in the `node-modules runtime-tar` output argument. This fixes tools/make-dist if the project root already contains the tarballs. That happens when a previous `packit propose-downstream` already ran and moved the tarballs to the project root. Fixes #22675
2025-12-15 00:21:30 -09:00
NODE_CACHE = $(CURDIR)/cockpit-node-$(VERSION).tar.xz
build: Create node runtime tarball as part of "make dist" The next commit we will require the `node-modules runtime-tar` tarball for building the debian/copyright file. Similarly to what cockpit-{podman,files} already do, change `make dist` to produce the node tarball as well, instead of making this a separate action. In tools/release, wrap the two generated tarballs into an outer `tar` so that we can squeeze both through the build container's stdout.
2025-12-04 12:30:46 -09:00
$(NODE_CACHE): $(srcdir)/package-lock.json
build: Fix inconsistent NODE_CACHE path We want NODE_CACHE to be a built file in the build dir. So declare that properly and use it at face value, instead of mangling the path in the `node-modules runtime-tar` output argument. This fixes tools/make-dist if the project root already contains the tarballs. That happens when a previous `packit propose-downstream` already ran and moved the tarballs to the project root. Fixes #22675
2025-12-15 00:21:30 -09:00
$(AM_V_GEN) $(srcdir)/tools/node-modules runtime-tar $(NODE_CACHE)
build: Create node runtime tarball as part of "make dist" The next commit we will require the `node-modules runtime-tar` tarball for building the debian/copyright file. Similarly to what cockpit-{podman,files} already do, change `make dist` to produce the node tarball as well, instead of making this a separate action. In tools/release, wrap the two generated tarballs into an outer `tar` so that we can squeeze both through the build container's stdout.
2025-12-04 12:30:46 -09:00
build: turn packaging files into proper rules Move all of our packaging-related files that we create at `make dist` out of `dist-hook` and into their own rules, with nice `$(AM_V_GEN)` output. Turn `dist-hook` into a pure list of dependencies on those files. Move the remaining rules into the main `distdir` target, which we were already overriding anyway. These will be dealt with in following commits.
2022-05-24 03:44:24 -08:00
dist-hook: $(distdir)/tools/debian/copyright
debian: Auto-generate debian/copyright Now that we ship the node modules tarball as part of the source, we need to document its copyrights and licenses. Update tools/build-debian-copyright to the version in cockpit-{files,podman} (we can drop their copies and import from cockpit afterwards), and adjust the copyright template accordingly: add missing licenses and update the comment about `dist/`.
2025-12-04 12:51:23 -09:00
# when building from a git checkout, we need to generate the copyright file
# when building from tarball (also separate build tree, dist-git), we can't
# rely on node_modules, so just copy the existing file
$(distdir)/tools/debian/copyright: $(srcdir)/tools/debian/copyright.template $(DIST_STAMP) $(if $(wildcard $(srcdir)/node_modules/.package-lock.json),$(NODE_CACHE))
Makefile.am: fix warning about @echo When we build images we get a warning like: /bin/sh: line 2: @echo: command not found from the expansion of `$(AM_V_GEN)` in the `tools/debian/copyright` rule. This expansion can contain a `@` in front of it but that's only valid at the start of a Makefile command, not in the middle of a shellscript. Move it out front to fix it, dropping the `@` that was there (which means that we'll now correctly see the command when we run with `V=1`).
2026-01-27 23:33:55 -09:00
$(AM_V_GEN) if [ -e "$(srcdir)/node_modules/.package-lock.json" ]; then \
$(srcdir)/tools/build-debian-copyright $< $(NODE_CACHE) > $@; \
debian: Auto-generate debian/copyright Now that we ship the node modules tarball as part of the source, we need to document its copyrights and licenses. Update tools/build-debian-copyright to the version in cockpit-{files,podman} (we can drop their copies and import from cockpit afterwards), and adjust the copyright template accordingly: add missing licenses and update the comment about `dist/`.
2025-12-04 12:51:23 -09:00
else \
Makefile.am: fix warning about @echo When we build images we get a warning like: /bin/sh: line 2: @echo: command not found from the expansion of `$(AM_V_GEN)` in the `tools/debian/copyright` rule. This expansion can contain a `@` in front of it but that's only valid at the start of a Makefile command, not in the middle of a shellscript. Move it out front to fix it, dropping the `@` that was there (which means that we'll now correctly see the command when we run with `V=1`).
2026-01-27 23:33:55 -09:00
cp "$(srcdir)/tools/debian/copyright" $@; \
debian: Auto-generate debian/copyright Now that we ship the node modules tarball as part of the source, we need to document its copyrights and licenses. Update tools/build-debian-copyright to the version in cockpit-{files,podman} (we can drop their copies and import from cockpit afterwards), and adjust the copyright template accordingly: add missing licenses and update the comment about `dist/`.
2025-12-04 12:51:23 -09:00
fi
build: turn packaging files into proper rules Move all of our packaging-related files that we create at `make dist` out of `dist-hook` and into their own rules, with nice `$(AM_V_GEN)` output. Turn `dist-hook` into a pure list of dependencies on those files. Move the remaining rules into the main `distdir` target, which we were already overriding anyway. These will be dealt with in following commits.
2022-05-24 03:44:24 -08:00
build: Make Python bridge the default Replace --enable-pybridge with --enable-old-bridge, and flip the logic. That way, it will slowly disappear as old distro releases become unsupported. This also means that builders from upstream now get the Python bridge by default. The distcheck scenarios now apply to the Python bridge. Add a `$DEB_PYTHON_INSTALL_LAYOUT` hack to work around https://bugs.debian.org/1035546 to unbreak the installation of the generated wrapper binaries, as by default they'd go into prefix/usr/local/bin on Debian. Add a new distcheck scenario for the C bridge, to ensure that we don't break that. https://issues.redhat.com/browse/COCKPIT-1037
2023-08-25 23:14:27 -08:00
DISTCHECK_CONFIGURE_FLAGS = --enable-prefix-only $(EXTRA_DISTCHECK_CONFIGURE_FLAGS)
Initial commit
2013-11-01 09:42:29 -08:00
test: Eliminate check-dist script This essentially does a single grep, move this to distcheck-hook. That avoids confusion with the integration tests, which also start with "check-*".
2022-06-21 01:25:24 -08:00
# Validate our AppStream metadata
distcheck-hook::
tools: Eliminate check-dist *.po files are already validated by the po-refresh bot, there is no need to do that again. Move the AppStream data validation directly into the Makefile, to avoid a separate shell script with just a single line. This also reduces confusion with the *other* check-dist script that we have in test/.
2022-06-21 01:13:33 -08:00
find $(distdir) -name '*.metainfo.xml' -o -name '*.appdata.xml' | xargs appstream-util validate --nonet
Makefile.am: group all dist-related stuff Move everything to do with `make dist` to a section at the top.
2022-03-09 02:34:18 -09:00
Update documentation and comments to not be webpack specific webpack is an implementation detail and soon change to esbuild. Make the verbiage more neutral.
2023-03-21 07:31:42 -08:00
# validate that we don't bundle the embedded patternfly font files, we use them from /static/fonts/
test: Eliminate check-dist script This essentially does a single grep, move this to distcheck-hook. That avoids confusion with the integration tests, which also start with "check-*".
2022-06-21 01:25:24 -08:00
distcheck-hook::
! grep --color=auto -rn "\.\./fonts/OpenSans\|fonts/.*eot\|truetype" $(distdir)/dist
Makefile.am: group all dist-related stuff Move everything to do with `make dist` to a section at the top.
2022-03-09 02:34:18 -09:00
# -----------------------------------------------------------------------------
TESTS = \
test: Move static-code into common/ It conceptually fits better there, as it's shared by all external projects. That makes importing easier as it doesn't have to be enumerated separately in COCKPIT_REPO_FILES any more.
2024-12-05 01:57:05 -09:00
test/common/static-code \
Makefile.am: group all dist-related stuff Move everything to do with `make dist` to a section at the top.
2022-03-09 02:34:18 -09:00
$(NULL)
clean-local::
find $(builddir) -name '*.gc??' -delete
find $(srcdir) -name '*.pyc' -delete
build: Drop chrome-remote-interface from release tarballs It's not necessary any more for running integration tests. Running the browser unit tests isn't supported from release tarballs anyway as we don't ship the pre-built quint tests.
2024-08-12 11:41:47 -08:00
# required for running integration tests
build: Move package-lock.json and FORCE rules to top-level Makefile `FORCE` is also a dependency of the `version.m4` target in the top-level Makefile.am, so it's confusing to only define it in the pkg/ subdirectory. Now it's only used in the top-level Makefile.am. `package-lock.json` is also a dependeny of po/Makefile.am, so it should also be shared and move to the top-level file. Consistently refer to it via `$(srcdir). `node_modules/*` also only gets referred to in the top-level Makefile.am for the EXTRA_DIST of the integration test dependencies. Move it next to that.
2023-03-20 21:42:53 -08:00
node_modules/%: $(srcdir)/package-lock.json
@true
build: set VERBOSE=1 on `make check` This causes the test-suite.log to be output at the end of the parallel test run, if any test failed. That log file contains only the failing tests, which makes it easier to find out exactly what went wrong. We can remove code from two unit-tests container scenarios that was basically doing exactly this.
2022-05-04 06:08:04 -08:00
check: export VERBOSE=1
build: remove `make test` qunit leftovers Support for running QUnit tests via the automake test harness was removed as part of 908ddb28ffdc but some bits and pieces remain. Remove them.
2024-07-03 20:29:45 -08:00
TEST_EXTENSIONS = .sh
tap-missing: Run a dummy TAP compiler when phantomjs is missing This just produces a 'Bail out!' TAP testing directive. Check for phantomjs in configure Reviewed-by: Marius Vollmer <marius.vollmer@redhat.com>
2014-02-26 21:54:30 -09:00
build: Fix valgrind invocation for HTML tests Using `$HTML_LOG_FLAGS` to inject valgrind is conceptually brittle, as it's not clear where exactly that gets shoved into the command line. At least Fedora 35's and Debian stable's automake versions (1.16.2 and .3) generate the test command with HTML_LOG_COMPILE = $(HTML_LOG_COMPILER) $(AM_HTML_LOG_FLAGS) $(HTML_LOG_FLAGS) which makes sense in general, but produces a command like tap-cdp ./test-server valgrind /source/dist/base1/test-user.html This makes no sense: valgrind immediately exits with "no program specified" and tests just hang. What we want is to run test-server under valgrind. It's not actually clear how this ever worked. Let's make the CLI ordering explicit: Stop using `$HTML_LOG_FLAGS` and use our own `$HTML_TEST_WRAPPER` variable, and inject it into the correct position between tap-cdp and test-server. Change `$VALGRIND_ARGS` to `$VALGRIND` and include the actual valgrind program, so that the whole wrapper is self-contained. With that, we can potentially run test-server under other tracers.
2022-07-12 22:02:25 -08:00
VALGRIND = valgrind --trace-children=yes --quiet --error-exitcode=33 --gen-suppressions=all \
build: fix valgrind --suppressions= logic The logic is broken for builddir != srcdir builds, since it doesn't include $(srcdir). It's also a bit silly to explicitly list all of the files when we can easily do it with `$(wildcard)`. Switch to `$(wildcard)`, include `$(srcdir)` and inline the whole thing.
2022-05-04 11:49:18 -08:00
$(foreach file,$(wildcard $(srcdir)/tools/*.supp),--suppressions=$(file)) \
Add leak checking for definite leaks to 'make check-memory' Closes #960 Reviewed-by: Marius Vollmer <marius.vollmer@redhat.com>
2014-08-01 00:49:41 -08:00
--num-callers=16 --leak-check=yes --show-leak-kinds=definite \
test: Don't blacklist cockpit-bridge and stub from memory leak checks
2017-09-25 23:27:44 -08:00
--errors-for-leak-kinds=definite --trace-children-skip='*mock*,/bin*,/usr/bin/*,/usr/local/bin'
Makefile.am: Add 'make check-memory' target which runs valgrind Add some basic suppressions files. These can be expanded. No leak checking yet, that's dependent on the glib wip/gcleanup branch and not yet ready. Reviewed-by: Marius Vollmer <marius.vollmer@redhat.com> Closes #246
2014-03-05 04:36:37 -09:00
build: stop generating valgrind-suppressions Valgrind takes multiple --suppressions arguments, so use that instead.
2022-02-25 06:44:52 -09:00
check-memory:
build: Fix valgrind invocation for HTML tests Using `$HTML_LOG_FLAGS` to inject valgrind is conceptually brittle, as it's not clear where exactly that gets shoved into the command line. At least Fedora 35's and Debian stable's automake versions (1.16.2 and .3) generate the test command with HTML_LOG_COMPILE = $(HTML_LOG_COMPILER) $(AM_HTML_LOG_FLAGS) $(HTML_LOG_FLAGS) which makes sense in general, but produces a command like tap-cdp ./test-server valgrind /source/dist/base1/test-user.html This makes no sense: valgrind immediately exits with "no program specified" and tests just hang. What we want is to run test-server under valgrind. It's not actually clear how this ever worked. Let's make the CLI ordering explicit: Stop using `$HTML_LOG_FLAGS` and use our own `$HTML_TEST_WRAPPER` variable, and inject it into the correct position between tap-cdp and test-server. Change `$VALGRIND_ARGS` to `$VALGRIND` and include the actual valgrind program, so that the whole wrapper is self-contained. With that, we can potentially run test-server under other tracers.
2022-07-12 22:02:25 -08:00
$(MAKE) LOG_FLAGS="$(VALGRIND)" \
tests: skip slow tests under valgrind Add a mechanism for skipping slow tests when requested by an environment variable (which we set, by default, when running tests under valgrind). Use this new API from the /ssh-bridge/echo-large test. For some reason, it's extremely slow under valgrind, particularly on i386 — slow enough that we're regularly hitting the alarm() timeout of 120 seconds on semaphore. Closes #12278
2019-07-10 04:05:33 -08:00
COCKPIT_SKIP_SLOW_TESTS=1 \
test: introduce a proper git pre-push hook This is based on running tools/test-static-code, which is now renamed to test/static-code. It is an improvement on using test-static-code as a pre-push hook, for the following reasons: - it checks each commit being pushed, finding code problems introduced in intermediate commits, even if they were fixed again after - it only runs on changed files, which speeds things up considerably - it uses the version of test-static-code that belongs to each commit that is being tested, instead of the one on the branch of the main worktree that happens to be symlinked to from the git hooks directory. This should eliminate future issues with improving the script and fixing code at the same time where the wrong version of the script would be run until all branches caught up to the changes. - it actually tests what is being pushed, rather than the contents of the current work tree, which is often — but not always — the same as what you're pushing. We also move a single check out of test/static-code, because it wasn't actually a code check, but rather a commit check. It's a much better fit in the pre-push hook itself. Please update your pre-push hook: ln -sf ../../test/git-hook-pre-push .git/hooks/pre-push
2022-01-12 11:04:14 -09:00
$(AM_MAKEFLAGS) check TESTS="$(filter-out test/% bots/%,$(TESTS))"
build: stop generating valgrind-suppressions Valgrind takes multiple --suppressions arguments, so use that instead.
2022-02-25 06:44:52 -09:00
recheck-memory:
build: Fix valgrind invocation for HTML tests Using `$HTML_LOG_FLAGS` to inject valgrind is conceptually brittle, as it's not clear where exactly that gets shoved into the command line. At least Fedora 35's and Debian stable's automake versions (1.16.2 and .3) generate the test command with HTML_LOG_COMPILE = $(HTML_LOG_COMPILER) $(AM_HTML_LOG_FLAGS) $(HTML_LOG_FLAGS) which makes sense in general, but produces a command like tap-cdp ./test-server valgrind /source/dist/base1/test-user.html This makes no sense: valgrind immediately exits with "no program specified" and tests just hang. What we want is to run test-server under valgrind. It's not actually clear how this ever worked. Let's make the CLI ordering explicit: Stop using `$HTML_LOG_FLAGS` and use our own `$HTML_TEST_WRAPPER` variable, and inject it into the correct position between tap-cdp and test-server. Change `$VALGRIND_ARGS` to `$VALGRIND` and include the actual valgrind program, so that the whole wrapper is self-contained. With that, we can potentially run test-server under other tracers.
2022-07-12 22:02:25 -08:00
$(MAKE) LOG_FLAGS="$(VALGRIND_ARGS)" \
Makefile.am: Add 'make check-memory' target which runs valgrind Add some basic suppressions files. These can be expanded. No leak checking yet, that's dependent on the glib wip/gcleanup branch and not yet ready. Reviewed-by: Marius Vollmer <marius.vollmer@redhat.com> Closes #246
2014-03-05 04:36:37 -09:00
$(AM_MAKEFLAGS) recheck
Makefile: Add bots target Closes #12875
2019-09-23 06:45:54 -08:00
# checkout Cockpit's bots for standard test VM images and API to launch them
various: bots now uses 'main' branch Make various changes to support that.
2021-07-04 00:41:00 -08:00
# must be from main, as only that has current and existing images; but testvm.py API is stable
build: Support CI testing against a bots project PR * If `$COCKPIT_BOTS_REF` is set, check out that bots version instead of master. * Use git cache in $XDG_CACHE_HOME if available. Our CI uses that to save downloads, and it does not get in the way for local developers. * Stop duplicating code in autogen.sh, just call `make bots`. The tree is configured at this point. Ported from https://github.com/cockpit-project/starter-kit/pull/233 Closes #12908
2019-10-02 12:19:02 -08:00
# support CI testing against a bots change
Makefile: Add bots target Closes #12875
2019-09-23 06:45:54 -08:00
bots:
tools: move make-bots, git-utils.sh to test/common This will allow our subprojects to benefit from the "full strength" implementation of 'get me bots/' with symlink and caching support.
2023-05-26 00:17:05 -08:00
test/common/make-bots
Makefile: Add bots target Closes #12875
2019-09-23 06:45:54 -08:00
build: add `make rsync` target This builds the tree, runs `make install` into a temporary DESTDIR, and then rsyncs the result to another host (default: `c`). This is intended to be used with the recently-added ./autogen.sh rpm feature in order to live-apply changes to a running VM image. An incremental `make rsync` after no changes takes less than one second. One note: at the present time, this has to be done on top of an already-prepared image with the cockpit packages installed. We use `--inplace` to assume the existing permissions and security context of the already-installed files. Without that, things will fail pretty quickly.
2022-02-07 03:45:39 -09:00
.PHONY: rsync
RSYNC_HOST ?= c
RSYNC_DEST ?= $(RSYNC_HOST):/
rsync:
$(MAKE)
$(MAKE) install DESTDIR=tmp/rsync >/dev/null
rsync --recursive --links --checksum --verbose --inplace tmp/rsync/ $(RSYNC_DEST)
build: lift docs rules out of toplevel Makefile This `if ENABLE_DOC` soup has no business being in the toplevel Makefile. Its reasons for being there are somewhat complicated, and have to do with automake's distaste for ::-style rules mixed with conditionals. We've often written rules like some-hook:: if ENABLE_DOC do_stuff endif for this reason. Invent a new approach that involves unconditionally adding a single dependency-only line for each hook, having it depend on a per-hook _TARGETS variable. The individual targets can now easily conditionally add themselves to the variable without triggering automake's wrath, which allows for things to be written much more cleanly. Neaten up the docs stuff accordingly, and move it to the makefile in doc/guide. Also use the dist_ trick (instead of EXTRA_DIST) to get files in the tarball regardless of which conditions are enabled.
2022-03-09 01:12:42 -09:00
# We use these to add conditionally-enabled extra rules
# automake doesn't like mixing `::` and `if`
CHECK_LOCAL_TARGETS =
.PHONY: $(CHECK_LOCAL_TARGETS)
check-local:: $(CHECK_LOCAL_TARGETS)
CLEAN_LOCAL_TARGETS =
.PHONY: $(CLEAN_LOCAL_TARGETS)
clean-local:: $(CLEAN_LOCAL_TARGETS)
INSTALL_DATA_LOCAL_TARGETS =
.PHONY: $(INSTALL_DATA_LOCAL_TARGETS)
install-data-local:: $(INSTALL_DATA_LOCAL_TARGETS)
build: tidy up cockpit-client symlink install The symlink in /usr/bin is conditionally installed via a hook, necessitating the evil pattern of introducing the conditional in the middle of a rule body. Adjust this to the new style of handling hook targets, as per the last commit.
2022-03-09 01:18:50 -09:00
INSTALL_EXEC_HOOK_TARGETS =
.PHONY: $(INSTALL_EXEC_HOOK_TARGETS)
install-exec-hook:: $(INSTALL_EXEC_HOOK_TARGETS)
build: lift docs rules out of toplevel Makefile This `if ENABLE_DOC` soup has no business being in the toplevel Makefile. Its reasons for being there are somewhat complicated, and have to do with automake's distaste for ::-style rules mixed with conditionals. We've often written rules like some-hook:: if ENABLE_DOC do_stuff endif for this reason. Invent a new approach that involves unconditionally adding a single dependency-only line for each hook, having it depend on a per-hook _TARGETS variable. The individual targets can now easily conditionally add themselves to the variable without triggering automake's wrath, which allows for things to be written much more cleanly. Neaten up the docs stuff accordingly, and move it to the makefile in doc/guide. Also use the dist_ trick (instead of EXTRA_DIST) to get files in the tarball regardless of which conditions are enabled.
2022-03-09 01:12:42 -09:00
UNINSTALL_LOCAL_TARGETS =
.PHONY: $(UNINSTALL_LOCAL_TARGETS)
uninstall-local:: $(UNINSTALL_LOCAL_TARGETS)
build: massive overhaul of build system Clean up the pkg-config and some `--enable-` flags usage in configure.ac. Stop defining AC_SUBST rules like COCKPIT_WS_CFLAGS and just let the pkg-config results go through. The Makefiles can decide for themselves which bits they want to use for each component. Create a new library, libcockpit-test.a, from the files in src/testlib/. This library gets linked from all test programs. Adjust all of the Makefiles in src/ to these two changes, and perform general cleanup. One major goal of this cleanup is to make standalone segments of the file for separate build targets. For example, adding a new unit test shouldn't involve adding it to a list in one place and then defining variables in another: this should all be done in one set of adjacent lines.
2022-03-06 22:50:12 -09:00
# This Makefile includes several variable definitions that must come first
include src/testlib/Makefile.am
Makefile.am: sort inclusions
2022-01-10 05:02:30 -09:00
include containers/Makefile.am
include containers/flatpak/Makefile.am
include doc/Makefile-doc.am
doc: Restructure prep for Antora support Antora uses a dedicated folder structure which we need to adhere to for it to work as it should. Makefiles has moved to `doc/` root to simplify the approach needed with Antora and AsciiDoctor. Existing bundling of documentation with help of AsciiDoctor works as normal and does not interfere with the directory change. Signed-off-by: Freya Gustavsson <freya@venefilyn.se>
2026-02-25 10:35:01 -09:00
include doc/Makefile-guide.am
include doc/Makefile-man.am
pkg: Less Makefile.am files in the pkg/ directory Consolidate into a single top level Makefile.am for things that haven't yet moved into webpack. Closes #4970 Reviewed-by: Lars Karlitski <lars@uebernic.de>
2016-09-06 05:55:21 -08:00
include pkg/Makefile.am
Makefile.am: sort inclusions
2022-01-10 05:02:30 -09:00
include po/Makefile.am
build: build selinux policy "upstream" Take the SELinux policy building out of the spec file and add a proper set of Makefile rules for it. Stop blanket-disting the selinux/ subdirectory, and treat it more like a normal source directory. The new rules are only enabled if --enable-selinux-policy=<type> is explicitly given. From the parts remaining in the spec file, clean them up a bit: remove the with_selinux conditional and use the pre- and post- rules unconditionally: we're only building the cockpit-ws package, anyway, in exactly the case that we'd want SELinux policy enabled. We can also make use of the macro provided by the selinux-policy package to avoid having to guess the version number for ourselves. We need to keep our own dependencies (instead of using %selinux_requires), though for two reasons: - chicken and egg problem: without a static BuildRequires on selinux-policy, the macros themselves wouldn't be available during the SRPM build, which means that we don't know that we need selinux-policy. - the post dependencies defined by the macro are a bit too aggressive and aren't conditional on selinux being available at all. This would break container builds, for example. Our %build stage now consists of a single %configure invocation and a single %make_build invocation.
2022-01-22 23:58:48 -09:00
include selinux/Makefile.am
build: move C flags to src/Makefile.am Add a new Makefile.am in src/ for things that only impact that directory.
2022-07-05 01:28:51 -08:00
include src/Makefile.am
branding: Add Arch Linux branding Add branding for the Arch Linux distribution, this requires the filesystem package to be installed which provides the Arch Linux logo.
2021-08-10 22:34:52 -08:00
include src/branding/arch/Makefile.am
branding: Move the branding directory into src/ This starts the move of all stable non-cockpit package parts into src. These parts will be continue to be built with a Makefile Closes #4634 Reviewed-by: Peter <petervo@redhat.com>
2016-06-25 12:21:56 -08:00
include src/branding/centos/Makefile.am
branding: Add Debian branding Closes #5240 Reviewed-by: Peter <petervo@redhat.com>
2016-10-26 08:40:54 -08:00
include src/branding/debian/Makefile.am
branding: Move the branding directory into src/ This starts the move of all stable non-cockpit package parts into src. These parts will be continue to be built with a Makefile Closes #4634 Reviewed-by: Peter <petervo@redhat.com>
2016-06-25 12:21:56 -08:00
include src/branding/default/Makefile.am
include src/branding/fedora/Makefile.am
branding: Use generic opensuse branding Closes #14713
2020-10-08 03:06:17 -08:00
include src/branding/opensuse/Makefile.am
branding: Move the branding directory into src/ This starts the move of all stable non-cockpit package parts into src. These parts will be continue to be built with a Makefile Closes #4634 Reviewed-by: Peter <petervo@redhat.com>
2016-06-25 12:21:56 -08:00
include src/branding/rhel/Makefile.am
branding: Add Ubuntu branding Ubuntu doesn't seem to have a logo installed outside of its plymouth login UI package. So we just use that, it's often there. Closes #5334 Reviewed-by: Peter <petervo@redhat.com>
2016-11-09 05:19:53 -09:00
include src/branding/ubuntu/Makefile.am
cockpit-client: split from cockpit-desktop Stop embedding a Python script inside of a shell script. Split it out to a separate file, installed in the same directory. This also gets us pycodestyle checking of the code, so fix up some issues that it found.
2021-11-23 04:58:30 -09:00
include src/client/Makefile.am
common: Rename cockpit/ subdirectory to common/ For new contributors it's confusing to have a directory named 'cockpit'. And clean up the last vestiges of libcockpit being an installable library. Reviewed-by: Marius Vollmer <marius.vollmer@redhat.com>
2014-06-25 04:03:42 -08:00
include src/common/Makefile-common.am
Makefile.am: sort inclusions
2022-01-10 05:02:30 -09:00
include src/pam-ssh-add/Makefile.am
ws: Move cockpit-session to src/session Our suid root program is quite different from cockpit-ws: It needs a lot more scrutinizing/review, and must minimize external dependencies (it's not using glib, for example). Move it to a separate src/session/ directory. This will also make future code cleanups easier.
2021-07-26 20:52:01 -08:00
include src/session/Makefile-session.am
src/systemd: new directory Our increasingly large web of systemd integration mostly lives in src/ws/, for mostly historical reasons. These days, cockpit-tls has at least as much integration with systemd as does cockpit-ws, and cockpit-session is about to gain some. Move everything to a new src/systemd/ directory.
2022-01-10 00:56:47 -09:00
include src/systemd/Makefile.am
tls: Add cockpit-tls proxy This program acts as a reverse TLS proxy for cockpit-ws, so that the TLS termination and client certificate validation will happen outside of cockpit-ws (which is too big to trust). Eventually it will run as a separate system user, but process isolation already improves security due to standard ptrace protection. cockpit-tls spawns separate cockpit-ws instances for each client certificate, TLS with no client certificate, and unencrypted HTTP. This prevents sniffing and tampering with credentials if attackers can coerce cockpit-ws to run arbitrary code. Adjust the systemd service to run cockpit-tls instead of cockpit-ws. Closes #12068
2019-04-15 02:30:56 -08:00
include src/tls/Makefile-tls.am
Makefile.am: sort inclusions
2022-01-10 05:02:30 -09:00
include src/ws/Makefile-ws.am
include tools/Makefile-tools.am
Reference in a new issue Copy permalink