max/nix-super
1
0
Fork 0
mirror of https://github.com/privatevoid-net/nix-super.git synced 2024-11-14 02:06:16 +02:00
Code Issues Projects Releases Packages Wiki Activity Actions
nix-super/tests/local.mk

161 lines
3.3 KiB
Makefile
Raw Normal View History

Add support for ‘make installcheck’
2013-11-25 19:47:03 +02:00
nix_tests = \
Harden tests' bash Use `set -u` and `set -o pipefail` to catch accidental mistakes and failures more strongly. - `set -u` catches the use of undefined variables - `set -o pipefail` catches failures (like `set -e`) earlier in the pipeline. This makes the tests a bit more robust. It is nice to read code not worrying about these spurious success paths (via uncaught) errors undermining the tests. Indeed, I caught some bugs doing this. There are a few tests where we run a command that should fail, and then search its output to make sure the failure message is one that we expect. Before, since the `grep` was the last command in the pipeline the exit code of those failing programs was silently ignored. Now with `set -o pipefail` it won't be, and we have to do something so the expected failure doesn't accidentally fail the test. To do that we use `expect` and a new `expectStderr` to check for the exact failing exit code. See the comments on each for why. `grep -q` is replaced with `grepQuiet`, see the comments on that function for why. `grep -v` when we just want the exit code is replaced with `grepInverse, see the comments on that function for why. `grep -q -v` together is, surprise surprise, replaced with `grepQuietInverse`, which is both combined. Co-authored-by: Robert Hensing <roberth@users.noreply.github.com>
2021-12-09 17:26:46 +02:00
test-infra.sh \
Make init.sh safe to run twice `init.sh` is tested on its own. We used to do that. I deleted it in 4720853129b6866775edd9f90ad6f10701f98a3c but I am not sure why. Better to just restore it; at one point working on this every other test passed, so seems good to check whether `init.sh` can be run twice. We don't *need* to run `init.sh` twice, but I want to try to make our tests as robust as possible so that manual debugging (where tests for better or worse might be run ways that we didn't expect) is less fragile.
2021-12-09 17:16:18 +02:00
init.sh \
Move flakes tests to a subdirectory
2022-07-13 15:09:35 +03:00
flakes/flakes.sh \
flakes/run.sh \
Split off the Mercurial flake tests
2022-07-13 15:40:39 +03:00
flakes/mercurial.sh \
Split off the circular flake import tests
2022-07-13 21:16:39 +03:00
flakes/circular.sh \
Split off 'nix flake init' tests
2022-07-13 21:36:11 +03:00
flakes/init.sh \
flakes: Ensure that `self.outPath == ./.` Users expect `self` to refer to the directory where the `flake.nix` file resides.
2023-02-09 23:10:30 +02:00
flakes/inputs.sh \
Split off following paths tests
2022-07-13 21:46:22 +03:00
flakes/follow-paths.sh \
Move the 'nix bundle' tests Note: these were previously not actually called.
2022-07-13 21:49:07 +03:00
flakes/bundle.sh \
Split off 'nix flake check' tests
2022-07-13 22:01:16 +03:00
flakes/check.sh \
Trivial changes from the lazy-trees branch
2022-12-07 13:58:58 +02:00
flakes/unlocked-override.sh \
flakes/absolute-paths.sh \
InstallableFlake::toDerivedPaths(): Support paths and store paths This makes 'nix build' work on paths (which will be copied to the store) and store paths (returned as is). E.g. the following flake output attributes can be built using 'nix build .#foo': foo = ./src; foo = self.outPath; foo = builtins.fetchTarball { ... }; foo = (builtins.fetchTree { .. }).outPath; foo = builtins.fetchTree { .. } + "/README.md"; foo = builtins.storePath /nix/store/...; Note that this is potentially risky, e.g. foo = /.; will cause Nix to try to copy the entire file system to the store. What doesn't work yet: foo = self; foo = builtins.fetchTree { .. }; because we don't handle attrsets with an outPath attribute in it yet, and foo = builtins.storePath /nix/store/.../README.md; since result symlinks have to point to a store path currently (rather than a file inside a store path). Fixes #7417.
2022-12-16 00:01:15 +02:00
flakes/build-paths.sh \
Add a test with flake.nix in a submodule I noticed a regression in the lazy-trees branch, which I'm trying to capture with this test. While the tests succeeds in master, the lazy-trees branch gives the following error message: error: access to path '/build/nix-test/tests/flakes/flake-in-submodule/rootRepo/submodule/flake.nix' is forbidden because it is not under Git control; maybe you should 'git add' it to the repository '/build/nix-test/tests/flakes/flake-in-submodule/rootRepo'?
2023-03-17 22:10:55 +02:00
flakes/flake-in-submodule.sh \
Add a test for the gc with CA derivations Also add a small architecture to easily run CA-enabled tests
2021-06-15 13:11:31 +03:00
ca/gc.sh \
Sort the tests by wall time The tests are scheduled in the order they appear, so running the long ones first slightly improves the scheduling. On my machine, this decreases the time of `make install` from 40s to 36s
2022-02-24 15:15:27 +02:00
gc.sh \
remote-store.sh \
Add `Store::isTrustedClient()` This function returns true or false depending on whether the Nix client is trusted or not. Mostly relevant when speaking to a remote store with a daemon. We include this information in `nix ping store` and `nix doctor` Co-Authored-By: John Ericson <John.Ericson@Obsidian.Systems>
2022-12-26 22:21:08 +02:00
legacy-ssh-store.sh \
Sort the tests by wall time The tests are scheduled in the order they appear, so running the long ones first slightly improves the scheduling. On my machine, this decreases the time of `make install` from 40s to 36s
2022-02-24 15:15:27 +02:00
lang.sh \
Write test, will fail until rest of PR
2023-01-17 02:10:18 +02:00
experimental-features.sh \
Sort the tests by wall time The tests are scheduled in the order they appear, so running the long ones first slightly improves the scheduling. On my machine, this decreases the time of `make install` from 40s to 36s
2022-02-24 15:15:27 +02:00
fetchMercurial.sh \
Add a test for auto-GC This currently fails because we're using POSIX file locks. So when the garbage collector opens and closes its own temproots file, it causes the lock to be released and then deleted by another GC instance.
2019-08-02 18:07:33 +03:00
gc-auto.sh \
Sort the tests by wall time The tests are scheduled in the order they appear, so running the long ones first slightly improves the scheduling. On my machine, this decreases the time of `make install` from 40s to 36s
2022-02-24 15:15:27 +02:00
user-envs.sh \
Test the migration of the user profiles
2022-04-13 11:26:50 +03:00
user-envs-migration.sh \
Test nix-build with non-local-store --store Just a few small things needed fixing!
2020-12-20 21:55:21 +02:00
binary-cache.sh \
Sort the tests by wall time The tests are scheduled in the order they appear, so running the long ones first slightly improves the scheduling. On my machine, this decreases the time of `make install` from 40s to 36s
2022-02-24 15:15:27 +02:00
multiple-outputs.sh \
ca/build.sh \
Test `nix build --json` return output paths in floating CA case Adding a test to ensure there is no regression. The tests that are split out of `tests/build.sh` are ones that don't yet work with CA derivation. I have not yet evaluated whether they should or not. This behavior, reported missing in issue #4661, already got fixed in PR #4818, but didn't get a test case then.
2021-03-01 02:15:05 +02:00
ca/new-build-cmd.sh \
Sort the tests by wall time The tests are scheduled in the order they appear, so running the long ones first slightly improves the scheduling. On my machine, this decreases the time of `make install` from 40s to 36s
2022-02-24 15:15:27 +02:00
nix-build.sh \
gc-concurrent.sh \
repair.sh \
fixed.sh \
export-graph.sh \
timeout.sh \
fetchGitRefs.sh \
gc-runtime.sh \
tarball.sh \
fetchGit.sh \
fetchurl.sh \
Implement simple test for `path`-fetcher setting a correct `lastModifiedDate` Co-authored-by: Théophane Hufschmitt <7226587+thufschmitt@users.noreply.github.com>
2022-03-15 13:55:32 +02:00
fetchPath.sh \
fetchTree: Allow fetching plain files Add a new `file` fetcher type, which will fetch a plain file over http(s), or from the local file. Because plain `http(s)://` or `file://` urls can already correspond to `tarball` inputs (if the path ends-up with a know archive extension), the URL parsing logic is a bit convuluted in that: - {http,https,file}:// urls will be interpreted as either a tarball or a file input, depending on the extensions of the path part (so `https://foo.com/bar` will be a `file` input and `https://foo.com/bar.tar.gz` as a `tarball` input) - `file+{something}://` urls will be interpreted as `file` urls (with the `file+` part removed) - `tarball+{something}://` urls will be interpreted as `tarball` urls (with the `tarball+` part removed) Fix #3785 Co-Authored-By: Tony Olagbaiye <me@fron.io>
2020-10-16 02:35:24 +03:00
fetchTree-file.sh \
Sort the tests by wall time The tests are scheduled in the order they appear, so running the long ones first slightly improves the scheduling. On my machine, this decreases the time of `make install` from 40s to 36s
2022-02-24 15:15:27 +02:00
simple.sh \
referrers.sh \
optimise-store.sh \
Check the CA hash when importing stuff in the local store When adding a path to the local store (via `LocalStore::addToStore`), ensure that the `ca` field of the provided `ValidPathInfo` does indeed correspond to the content of the path. Otherwise any untrusted user (or any binary cache) can add arbitrary content-addressed paths to the store (as content-addressed paths don’t need a signature).
2021-05-27 14:25:25 +03:00
substitute-with-invalid-ca.sh \
Sort the tests by wall time The tests are scheduled in the order they appear, so running the long ones first slightly improves the scheduling. On my machine, this decreases the time of `make install` from 40s to 36s
2022-02-24 15:15:27 +02:00
ca/concurrent-builds.sh \
signing.sh \
ca/build-with-garbage-path.sh \
hash.sh \
gc-non-blocking.sh \
check.sh \
ca/substitute.sh \
nix-shell.sh \
ca/signatures.sh \
ca/nix-shell.sh \
ca/nix-copy.sh \
check-refs.sh \
Merge remote-tracking branch 'upstream/master' into trustless-remote-builder-simple
2020-08-14 19:05:27 +03:00
build-remote-input-addressed.sh \
Sort the tests by wall time The tests are scheduled in the order they appear, so running the long ones first slightly improves the scheduling. On my machine, this decreases the time of `make install` from 40s to 36s
2022-02-24 15:15:27 +02:00
secure-drv-outputs.sh \
restricted.sh \
fetchGitSubmodules.sh \
Move flake-searching.sh and make it less dependent on git
2022-07-13 21:55:08 +03:00
flakes/search-root.sh \
Sort the tests by wall time The tests are scheduled in the order they appear, so running the long ones first slightly improves the scheduling. On my machine, this decreases the time of `make install` from 40s to 36s
2022-02-24 15:15:27 +02:00
ca/duplicate-realisation-in-closure.sh \
readfile-context.sh \
nix-channel.sh \
recursive.sh \
dependencies.sh \
check-reqs.sh \
Restore now-working build-remote-content-addressed-fixed test This was - Added in dbf96e10ecc75410c9db798f208f8a8310842a4f. - Commented out in 07975979aae4e7729ae13ffeb7390d07d71ad4bd, which I believe only reached master by mistake. - Deleted in c32168c9bc161e0c9cea027853895971699510cb, when `tests/build-hook-ca.nix` was reused for a new test. But the test works, and we ought to have it.
2021-02-26 18:29:19 +02:00
build-remote-content-addressed-fixed.sh \
Test the remote building of ca derivations
2021-01-26 11:28:00 +02:00
build-remote-content-addressed-floating.sh \
Reenable previously failing trustless remote builder tests
2021-02-27 07:33:47 +02:00
build-remote-trustless-should-pass-0.sh \
Trustless remote building Co-authored-by: Matthew Bauer <mjbauer95@gmail.com>
2020-08-12 06:47:36 +03:00
build-remote-trustless-should-pass-1.sh \
build-remote-trustless-should-pass-2.sh \
Reenable previously failing trustless remote builder tests
2021-02-27 07:33:47 +02:00
build-remote-trustless-should-pass-3.sh \
Trustless remote building Co-authored-by: Matthew Bauer <mjbauer95@gmail.com>
2020-08-12 06:47:36 +03:00
build-remote-trustless-should-fail-0.sh \
Rename tests/nar-index -> tests/nar-access
2017-11-14 14:27:40 +02:00
nar-access.sh \
Sort the tests by wall time The tests are scheduled in the order they appear, so running the long ones first slightly improves the scheduling. On my machine, this decreases the time of `make install` from 40s to 36s
2022-02-24 15:15:27 +02:00
pure-eval.sh \
add tests for nix eval and nix-instantiate
2022-03-16 20:57:18 +02:00
eval.sh \
Sort the tests by wall time The tests are scheduled in the order they appear, so running the long ones first slightly improves the scheduling. On my machine, this decreases the time of `make install` from 40s to 36s
2022-02-24 15:15:27 +02:00
ca/post-hook.sh \
repl.sh \
ca/repl.sh \
ca/recursive.sh \
binary-cache-build-remote.sh \
search.sh \
logging.sh \
export.sh \
config.sh \
add.sh \
local-store.sh \
filter-source.sh \
misc.sh \
dump-db.sh \
linux-sandbox.sh \
build-dry.sh \
Add fetchMercurial primop E.g. $ nix eval '(fetchMercurial https://www.mercurial-scm.org/repo/hello)' { branch = "default"; outPath = "/nix/store/alvb9y1kfz42bjishqmyy3pphnrh1pfa-source"; rev = "82e55d328c8ca4ee16520036c0aaace03a5beb65"; revCount = 1; shortRev = "82e55d328c8c"; } $ nix eval '(fetchMercurial { url = https://www.mercurial-scm.org/repo/hello; rev = "0a04b987be5ae354b710cefeba0e2d9de7ad41a9"; })' { branch = "default"; outPath = "/nix/store/alvb9y1kfz42bjishqmyy3pphnrh1pfa-source"; rev = "0a04b987be5ae354b710cefeba0e2d9de7ad41a9"; revCount = 0; shortRev = "0a04b987be5a"; } $ nix eval '(fetchMercurial /tmp/unclean-hg-tree)' { branch = "default"; outPath = "/nix/store/cm750cdw1x8wfpm3jq7mz09r30l9r024-source"; rev = "0000000000000000000000000000000000000000"; revCount = 0; shortRev = "000000000000"; }
2017-11-01 17:32:53 +02:00
structured-attrs.sh \
rename run to shell in tests
2020-04-30 00:37:21 +03:00
shell.sh \
Add pure evaluation mode In this mode, the following restrictions apply: * The builtins currentTime, currentSystem and storePath throw an error. * $NIX_PATH and -I are ignored. * fetchGit and fetchMercurial require a revision hash. * fetchurl and fetchTarball require a sha256 attribute. * No file system access is allowed outside of the paths returned by fetch{Git,Mercurial,url,Tarball}. Thus 'nix build -f ./foo.nix' is not allowed. Thus, the evaluation result is completely reproducible from the command line arguments. E.g. nix build --pure-eval '( let nix = fetchGit { url = https://github.com/NixOS/nixpkgs.git; rev = "9c927de4b179a6dd210dd88d34bda8af4b575680"; }; nixpkgs = fetchGit { url = https://github.com/NixOS/nixpkgs.git; ref = "release-17.09"; rev = "66b4de79e3841530e6d9c6baf98702aa1f7124e4"; }; in (import (nix + "/release.nix") { inherit nix nixpkgs; }).build.x86_64-linux )' The goal is to enable completely reproducible and traceable evaluation. For example, a NixOS configuration could be fully described by a single Git commit hash. 'nixos-rebuild' would do something like nix build --pure-eval '( (import (fetchGit { url = file:///my-nixos-config; rev = "..."; })).system ') where the Git repository /my-nixos-config would use further fetchGit calls or Git externals to fetch Nixpkgs and whatever other dependencies it has. Either way, the commit hash would uniquely identify the NixOS configuration and allow it to reproduced.
2018-01-16 19:50:38 +02:00
brotli.sh \
add tests for zstd compression
2021-04-10 00:13:08 +03:00
zstd.sh \
Add compression level for NARs Based off on @dtzWill's #2276
2021-10-12 09:14:36 +03:00
compression-levels.sh \
Add basic flake tests
2019-05-08 00:22:47 +03:00
nix-copy-ssh.sh \
Merge remote-tracking branch 'origin/master' into flakes
2019-08-08 16:49:13 +03:00
post-hook.sh \
Merge remote-tracking branch 'origin/master' into flakes
2019-08-29 17:11:38 +03:00
function-trace.sh \
Move flake-local-settings.sh
2022-07-13 21:51:28 +03:00
flakes/config.sh \
nix-fmt: add command
2022-03-11 15:57:28 +02:00
fmt.sh \
Add test for readFile keeping context
2017-11-11 00:51:34 +02:00
eval-store.sh \
Sort the tests by wall time The tests are scheduled in the order they appear, so running the long ones first slightly improves the scheduling. On my machine, this decreases the time of `make install` from 40s to 36s
2022-02-24 15:15:27 +02:00
why-depends.sh \
Increase the test coverage of `why-depends` - Test with `--derivation` - Actually test with ca-derivations (was suuposedly done, but not activated because of a missing line in `local.mk`)
2023-01-02 17:09:03 +02:00
ca/why-depends.sh \
Create `nix derivation add` command Also refine `nix derivation show`'s docs very slightly.
2023-02-18 01:37:35 +02:00
derivation-json.sh \
ca/derivation-json.sh \
Sort the tests by wall time The tests are scheduled in the order they appear, so running the long ones first slightly improves the scheduling. On my machine, this decreases the time of `make install` from 40s to 36s
2022-02-24 15:15:27 +02:00
import-derivation.sh \
ca/import-derivation.sh \
Make `tests/dyn-drv` test dir
2023-04-20 01:49:50 +03:00
dyn-drv/text-hashed-output.sh \
Add a more interesting test In this one, we don't just output an existing derivation as is, but modify it first.
2023-04-20 03:36:33 +03:00
dyn-drv/recursive-mod-json.sh \
Don’t require `NIX_PATH` entries to be valid paths It’s totally valid to have entries in `NIX_PATH` that aren’t valid paths (they can even be arbitrary urls or `channel:<channel-name>`). Fix #5998 and #5980
2022-01-27 16:32:14 +02:00
nix_path.sh \
Sort the tests by wall time The tests are scheduled in the order they appear, so running the long ones first slightly improves the scheduling. On my machine, this decreases the time of `make install` from 40s to 36s
2022-02-24 15:15:27 +02:00
case-hack.sh \
placeholders.sh \
ssh-relay.sh \
plugins.sh \
Add x86_64 compute levels as additional system types When performing distributed builds of machine learning packages, it would be nice if builders without the required SIMD instructions can be excluded as build nodes. Since x86_64 has accumulated a large number of different instruction set extensions, listing all possible extensions would be unwieldy. AMD, Intel, Red Hat, and SUSE have recently defined four different microarchitecture levels that are now part of the x86-64 psABI supplement and will be used in glibc 2.33: https://gitlab.com/x86-psABIs/x86-64-ABI https://lwn.net/Articles/844831/ This change uses libcpuid to detect CPU features and then uses them to add the supported x86_64 levels to the additional system types. For example on a Ryzen 3700X: $ ~/aps/bin/nix -vv --version | grep "Additional system" Additional system types: i686-linux, x86_64-v1-linux, x86_64-v2-linux, x86_64-v3-linux
2021-02-16 15:32:12 +02:00
build.sh \
Test `nix build --json` return output paths in floating CA case Adding a test to ensure there is no regression. The tests that are split out of `tests/build.sh` are ones that don't yet work with CA derivation. I have not yet evaluated whether they should or not. This behavior, reported missing in issue #4661, already got fixed in PR #4818, but didn't get a test case then.
2021-03-01 02:15:05 +02:00
build-delete.sh \
output-normalization.sh \
Add a test for `nix run` with CA derivations
2021-05-11 11:52:17 +03:00
ca/nix-run.sh \
nix: add (failing) selfreference test for multiple realizations The test illustrates failure in issue #5320. Here derivation and it's built input have identical CA sotre path. As a result we generate extraneout reference to build input: $ make installcheck ... ran test tests/selfref-gc.sh... [PASS] ran test tests/ca/selfref-gc.sh... [FAIL] ... deleting '/tmp/.../tests/ca/selfref-gc/store/iqciq1mpg5hc7p6a52fp2bjxbyc9av0v-selfref-gc' deleting '/tmp/...tests/ca/selfref-gc/store/zh0kwpnirw3qbv6dl1ckr1y0kd5aw6ax-selfref-gc.drv' error: executing SQLite statement 'delete from ValidPaths where path = '/tmp/.../tests/ca/selfref-gc/store/fsjq0k146r85lsh01l0icl30rnhv7z72-selfref-gc';': constraint failed (in '/tmp/.../tests/ca/selfref-gc/var/nix/db/db.sqlite')
2021-10-04 11:00:01 +03:00
selfref-gc.sh ca/selfref-gc.sh \
Sort the tests by wall time The tests are scheduled in the order they appear, so running the long ones first slightly improves the scheduling. On my machine, this decreases the time of `make install` from 40s to 36s
2022-02-24 15:15:27 +02:00
db-migration.sh \
tests: Rename nix-profile.sh -> bash-profile.sh
2022-03-02 12:14:31 +02:00
bash-profile.sh \
Sort the tests by wall time The tests are scheduled in the order they appear, so running the long ones first slightly improves the scheduling. On my machine, this decreases the time of `make install` from 40s to 36s
2022-02-24 15:15:27 +02:00
pass-as-file.sh \
Add some end-to-end tests for the suggestions
2022-03-04 11:29:48 +02:00
nix-profile.sh \
suggestions.sh \
Add a test for fetchClosure and 'nix store make-content-addressed'
2022-03-23 00:19:21 +02:00
store-ping.sh \
Add support for impure derivations Impure derivations are derivations that can produce a different result every time they're built. Example: stdenv.mkDerivation { name = "impure"; __impure = true; # marks this derivation as impure outputHashAlgo = "sha256"; outputHashMode = "recursive"; buildCommand = "date > $out"; }; Some important characteristics: * This requires the 'impure-derivations' experimental feature. * Impure derivations are not "cached". Thus, running "nix-build" on the example above multiple times will cause a rebuild every time. * They are implemented similar to CA derivations, i.e. the output is moved to a content-addressed path in the store. The difference is that we don't register a realisation in the Nix database. * Pure derivations are not allowed to depend on impure derivations. In the future fixed-output derivations will be allowed to depend on impure derivations, thus forming an "impurity barrier" in the dependency graph. * When sandboxing is enabled, impure derivations can access the network in the same way as fixed-output derivations. In relaxed sandboxing mode, they can access the local filesystem.
2022-03-30 17:31:01 +03:00
fetchClosure.sh \
Fix the name of the completions test
2022-07-12 10:19:05 +03:00
completions.sh \
Add a test for `nix flake show`
2023-01-27 11:13:05 +02:00
flakes/show.sh \
Add command 'nix store path-from-hash-part' This exposes the Store::queryPathFromHashPart() interface in the CLI.
2022-10-18 17:42:06 +03:00
impure-derivations.sh \
Trivial changes from the lazy-trees branch
2022-12-07 13:58:58 +02:00
path-from-hash-part.sh \
Add tests for read-only local store Make sure we don't go down the path of making temproots when doing operations on a read-only store
2023-05-17 21:48:59 +03:00
toString-path.sh \
read-only-store.sh
Add support for ‘make installcheck’
2013-11-25 19:47:03 +02:00
Make libcpuid dependency optional with --disable-cpuid
2021-11-28 01:48:04 +02:00
ifeq ($(HAVE_LIBCPUID), 1)
nix_tests += compute-levels.sh
endif
Add support for ‘make installcheck’
2013-11-25 19:47:03 +02:00
Make `tests/dyn-drv` test dir
2023-04-20 01:49:50 +03:00
install-tests += $(foreach x, $(nix_tests), $(d)/$(x))
Add support for ‘make installcheck’
2013-11-25 19:47:03 +02:00
Make `tests/dyn-drv` test dir
2023-04-20 01:49:50 +03:00
clean-files += \
$(d)/common/vars-and-functions.sh \
$(d)/config.nix \
$(d)/ca/config.nix \
$(d)/dyn-drv/config.nix
Add support for ‘make installcheck’
2013-11-25 19:47:03 +02:00
Make `tests/dyn-drv` test dir
2023-04-20 01:49:50 +03:00
test-deps += \
tests/common/vars-and-functions.sh \
tests/config.nix \
Fix typo in tests
2023-04-20 03:47:23 +03:00
tests/ca/config.nix \
tests/dyn-drv/config.nix
Add basic flake tests
2019-05-08 00:22:47 +03:00
Enable/fix tests in nix-static pkgsStatic is apparently considered a cross environment, so checkPhase and installCheckPhase are disabled even when we ask for them.
2022-06-22 23:41:14 +03:00
ifeq ($(BUILD_SHARED_LIBS), 1)
test-deps += tests/plugins/libplugintest.$(SO_EXT)
endif
Reference in a new issue Copy permalink