Incorporate some lint checks into `meson test`
This will make it easier and more obvious for developers to run them
locally: I'm sure I'm not the only developer who had assumed that
`.gitlab-ci/` is private to the CI environment and inappropriate (or
perhaps even destructive) to run on a developer/user system.
The lint checks are automatically skipped (with TAP SKIP syntax) if we
are not in a git checkout, or if git or the lint tool is missing. They
can also be disabled explicitly with `meson test --no-suite=lint`,
which downstream distributions will probably want to do.
By default, most lint checks are reported as an "expected failure"
(with TAP TODO syntax) rather than a hard failure, because they do not
indicate a functional problem with GLib and there is a tendency for
lint tools to introduce additional checks or become more strict over
time. Developers can override this by configuring with `-Dwerror=true`
(which also makes compiler warnings into fatal errors), or by running
the test suite like `LINT_WARNINGS_ARE_ERRORS=1 meson test --suite=lint`.
One exception to this is tests/check-missing-install-tag.py, which is
checking a functionally significant feature of our build system, and
seems like it is unlikely to have false positives: if that one fails,
it is reported as a hard failure.
run-style-check-diff.sh and run-check-todos.sh are not currently given
this treatment, because they require search-common-ancestor.sh, which
uses Gitlab-CI-specific information to find out which commits are in-scope
for checking.
Signed-off-by: Simon McVittie <smcv@collabora.com>
2024-02-07 12:16:22 +00:00
|
|
|
# Copyright 2024 Collabora Ltd.
|
|
|
|
|
# SPDX-License-Identifier: LGPL-2.1-or-later
|
|
|
|
|
|
2024-03-15 14:49:27 +00:00
|
|
|
test_env = environment()
|
|
|
|
|
test_env.set('G_TEST_SRCDIR', meson.current_source_dir())
|
|
|
|
|
test_env.set('G_TEST_BUILDDIR', meson.current_build_dir())
|
|
|
|
|
|
Incorporate some lint checks into `meson test`
This will make it easier and more obvious for developers to run them
locally: I'm sure I'm not the only developer who had assumed that
`.gitlab-ci/` is private to the CI environment and inappropriate (or
perhaps even destructive) to run on a developer/user system.
The lint checks are automatically skipped (with TAP SKIP syntax) if we
are not in a git checkout, or if git or the lint tool is missing. They
can also be disabled explicitly with `meson test --no-suite=lint`,
which downstream distributions will probably want to do.
By default, most lint checks are reported as an "expected failure"
(with TAP TODO syntax) rather than a hard failure, because they do not
indicate a functional problem with GLib and there is a tendency for
lint tools to introduce additional checks or become more strict over
time. Developers can override this by configuring with `-Dwerror=true`
(which also makes compiler warnings into fatal errors), or by running
the test suite like `LINT_WARNINGS_ARE_ERRORS=1 meson test --suite=lint`.
One exception to this is tests/check-missing-install-tag.py, which is
checking a functionally significant feature of our build system, and
seems like it is unlikely to have false positives: if that one fails,
it is reported as a hard failure.
run-style-check-diff.sh and run-check-todos.sh are not currently given
this treatment, because they require search-common-ancestor.sh, which
uses Gitlab-CI-specific information to find out which commits are in-scope
for checking.
Signed-off-by: Simon McVittie <smcv@collabora.com>
2024-02-07 12:16:22 +00:00
|
|
|
lint_scripts = [
|
|
|
|
|
'black.sh',
|
|
|
|
|
'flake8.sh',
|
|
|
|
|
'reuse.sh',
|
|
|
|
|
'shellcheck.sh',
|
|
|
|
|
]
|
|
|
|
|
|
2024-02-12 14:15:51 +00:00
|
|
|
if have_bash
|
|
|
|
|
foreach test_name : lint_scripts
|
|
|
|
|
test(
|
2024-08-27 11:25:42 -07:00
|
|
|
test_name,
|
|
|
|
|
bash,
|
|
|
|
|
args : [files(test_name)],
|
2024-03-15 14:49:27 +00:00
|
|
|
env : test_env,
|
2024-02-13 08:41:59 +00:00
|
|
|
suite : ['lint', 'no-valgrind'],
|
2024-02-12 14:15:51 +00:00
|
|
|
protocol : 'tap',
|
|
|
|
|
)
|
|
|
|
|
endforeach
|
|
|
|
|
endif
|
Incorporate some lint checks into `meson test`
This will make it easier and more obvious for developers to run them
locally: I'm sure I'm not the only developer who had assumed that
`.gitlab-ci/` is private to the CI environment and inappropriate (or
perhaps even destructive) to run on a developer/user system.
The lint checks are automatically skipped (with TAP SKIP syntax) if we
are not in a git checkout, or if git or the lint tool is missing. They
can also be disabled explicitly with `meson test --no-suite=lint`,
which downstream distributions will probably want to do.
By default, most lint checks are reported as an "expected failure"
(with TAP TODO syntax) rather than a hard failure, because they do not
indicate a functional problem with GLib and there is a tendency for
lint tools to introduce additional checks or become more strict over
time. Developers can override this by configuring with `-Dwerror=true`
(which also makes compiler warnings into fatal errors), or by running
the test suite like `LINT_WARNINGS_ARE_ERRORS=1 meson test --suite=lint`.
One exception to this is tests/check-missing-install-tag.py, which is
checking a functionally significant feature of our build system, and
seems like it is unlikely to have false positives: if that one fails,
it is reported as a hard failure.
run-style-check-diff.sh and run-check-todos.sh are not currently given
this treatment, because they require search-common-ancestor.sh, which
uses Gitlab-CI-specific information to find out which commits are in-scope
for checking.
Signed-off-by: Simon McVittie <smcv@collabora.com>
2024-02-07 12:16:22 +00:00
|
|
|
|
2025-02-28 11:52:09 +00:00
|
|
|
if not meson.is_subproject()
|
|
|
|
|
test(
|
|
|
|
|
'check-missing-install-tag.py',
|
|
|
|
|
python,
|
|
|
|
|
args : ['-B', files('check-missing-install-tag.py')],
|
|
|
|
|
env : test_env,
|
|
|
|
|
suite : ['lint', 'no-valgrind'],
|
|
|
|
|
protocol : 'tap',
|
|
|
|
|
)
|
|
|
|
|
endif
|
2025-02-04 19:13:40 +01:00
|
|
|
|
2025-02-21 12:35:16 +00:00
|
|
|
subdir('lib')
|