History log of /openbmc/openbmc-build-scripts/scripts/unit-test.py (Results 1 – 25 of 174)
Revision Date Author Comments
# bc5f06f5 05-Mar-2025 Lei YU <yulei.sh@bytedance.com>

unit-test: Set to none after sanitizer

The unit test contains a step to do sanitize test by
`-Db_sanitize=address,undefined`, and remove the config after it's done.
However, the meson generated `com

unit-test: Set to none after sanitizer

The unit test contains a step to do sanitize test by
`-Db_sanitize=address,undefined`, and remove the config after it's done.
However, the meson generated `compile_commands.json` still contains the
`-fsanitize=address,undefined` compile option. If we run the unit test
again, it will cause valgrind test reporting error as below:

```
ASan runtime does not come first in initial library list; you should either link runtime to your application or manually preload it with LD_PRELOAD.
```

To correctly disable sanitizer, `-Db_sanitize=none` is needed to
specifically tell meson to disable it.

Tested: Run sdbusplus's unit test twice without issue. Without this
change, the second run will get the above valgrind error.

Signed-off-by: Lei YU <yulei.sh@bytedance.com>
Change-Id: Iebde8ce80b498a039de4f2713b5c16561ca63b09

show more ...


# 966d67da 10-Mar-2025 Ed Tanous <etanous@nvidia.com>

Use clang as C compiler

When setting up the clang build, use clang as the C compiler and the C++
compiler. This matters for C libraries where we might want to set up
fuzzing. Having the C portions

Use clang as C compiler

When setting up the clang build, use clang as the C compiler and the C++
compiler. This matters for C libraries where we might want to set up
fuzzing. Having the C portions compile with GCC prevents compiling with
libfuzzer flags.

Change-Id: I113693bc139f4ebb58107e3df26ee82cc460f460
Signed-off-by: Ed Tanous <etanous@nvidia.com>

show more ...


# f0e5de91 21-Feb-2025 Ewelina Walkusz <ewelinax.walkusz@intel.com>

unit-test: Remove `UBSAN_OPTIONS=halt_on_error=1`

Setting `UBSAN_OPTIONS=halt_on_error=1` here makes adding the
`UBSAN_OPTION` environment variable ineffective (like
`suppressions=ubsan.supp` or `pr

unit-test: Remove `UBSAN_OPTIONS=halt_on_error=1`

Setting `UBSAN_OPTIONS=halt_on_error=1` here makes adding the
`UBSAN_OPTION` environment variable ineffective (like
`suppressions=ubsan.supp` or `print_summary=1`). This environment
variable is always overwritten.

The mechanism that makes UBSAN kill tests is no longer needed when using
meson version 1.3.0 or higher
https://github.com/mesonbuild/meson/commit/7b7d2e060b where default
```
UBSAN_OPTION=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1
```

Resolves: openbmc/openbmc-build-scripts#43

Tested:
- Run `run-unit-test-docker.sh` without setting env variable, with
`invalid vptr` error - tests failed with more info in logs (stack trace,
summary)
- Run `run-unit-test-docker.sh` with setting env variable
`UBSAN_OPTION=suppressions=ubsan.supp` with suppression for vptr check
and with bug location - tests passed

Change-Id: I64eb799645dbc9cde4b7ee75098b641ebe30a5a4
Signed-off-by: Ewelina Walkusz <ewelinax.walkusz@intel.com>

show more ...


# d8e150a5 04-Feb-2025 Ewelina Walkusz <ewelinax.walkusz@intel.com>

unit-test: Add ability to skip cppcheck

Now you can run openbmc-build-scripts/run-unit-test-docker.sh with
`NO_CPPCHECK=1` to skip cppcheck

We need this mechanizm in case cppcheck hangs. This probl

unit-test: Add ability to skip cppcheck

Now you can run openbmc-build-scripts/run-unit-test-docker.sh with
`NO_CPPCHECK=1` to skip cppcheck

We need this mechanizm in case cppcheck hangs. This problem can occur
when compiling with the BOOST_NO_RTTI and BOOST_NO_TYPEID flags.

Tested:
- Run `run-unit-test-docker.sh` as before, verify cppcheck runs
- Run `NO_CPPCHECK=1 run-unit-test-docker.sh`, verify cppcheck is
skipped

Change-Id: Ib1b246dc932b3b36334bfbe51934c206bdeb936f
Signed-off-by: Ewelina Walkusz <ewelinax.walkusz@intel.com>

show more ...


# 5618dd5c 20-Jan-2025 Ewelina Walkusz <ewelinax.walkusz@intel.com>

build-unit-test-docker: upgrade meson to 1.6.1

Tested: run-unit-test-docker.sh runs correctly

Change-Id: Ifa4bc74d707d1c0b12bf9b147fd03e0e3c075262
Signed-off-by: Ewelina Walkusz <ewelinax.walkusz@i

build-unit-test-docker: upgrade meson to 1.6.1

Tested: run-unit-test-docker.sh runs correctly

Change-Id: Ifa4bc74d707d1c0b12bf9b147fd03e0e3c075262
Signed-off-by: Ewelina Walkusz <ewelinax.walkusz@intel.com>

show more ...


# 52c3aec3 22-Jan-2025 Ewelina Walkusz <ewelinax.walkusz@intel.com>

unit-test: Reconfigure after sanitizers

After running `meson configure build -Db_sanitize=none`, there may be
leftovers that cause the next analysis to fail:
`ASan runtime does not come first in ini

unit-test: Reconfigure after sanitizers

After running `meson configure build -Db_sanitize=none`, there may be
leftovers that cause the next analysis to fail:
`ASan runtime does not come first in initial library list; you should
either link runtime to your application or manually preload it with
LD_PRELOAD.`

Fixes: openbmc/openbmc-build-scripts#42

Change-Id: Ia5b3c6c8a076c61aadd70ab23c029c591a3e29f5
Signed-off-by: Ewelina Walkusz <ewelinax.walkusz@intel.com>

show more ...


# fb6653ce 15-Jul-2024 Ewelina Walkusz <ewelinax.walkusz@intel.com>

build-unit-test-docker: upgrade meson to 1.5.1

Poky is using meson 1.5.1

Tested: run-unit-test-docker.sh runs correctly

Change-Id: I9b4b27b72118dcb15a9616ca78edf8a087cd4481
Signed-off-by: Ewelina

build-unit-test-docker: upgrade meson to 1.5.1

Poky is using meson 1.5.1

Tested: run-unit-test-docker.sh runs correctly

Change-Id: I9b4b27b72118dcb15a9616ca78edf8a087cd4481
Signed-off-by: Ewelina Walkusz <ewelinax.walkusz@intel.com>

show more ...


# 33aec43b 09-Oct-2024 Johnathan Mantey <johnathanx.mantey@intel.com>

Ensure address sanitize operation builds all components

The 'meson configure' call designed to enable address sanitize checks,
under some circumstances, prevents shared objects supplied from
subproj

Ensure address sanitize operation builds all components

The 'meson configure' call designed to enable address sanitize checks,
under some circumstances, prevents shared objects supplied from
subprojects from being rebuilt.

Using a 'setup reconfigure' operation allows the shared libraries to
be built for the address sanitization phase. Instead of receiving
segmentation faults for missing libraries, the tests run to
completion.

Tested:
Ran the CI script w/o these changes and saw the sanitize portion fail
due to missing libraries.
Installed the changes, and the CI script passed the sanitize section
because the shared libraries were built.

Change-Id: I60fef2518ec13ffbcc615e55f8f446cf92f4dd0a
Signed-off-by: Johnathan Mantey <johnathanx.mantey@intel.com>

show more ...


# d40ad0be 30-Sep-2024 Johnathan Mantey <johnathanx.mantey@intel.com>

Refresh the shared library cache after new libraries installed

The internal _test_one function installs built objects. The Meson
recipes for these objects may place shared libraries into the
/usr/lo

Refresh the shared library cache after new libraries installed

The internal _test_one function installs built objects. The Meson
recipes for these objects may place shared libraries into the
/usr/local/lib directory. When the install process completes the
shared library cache becomes stale. In order for the follow up actions
of test() and anaylyze() to succeed the shared library cache needs to
be updated.

Tested:
Invoked the CI Docker image on a project that included several
subprojects.
Manually invoked each script check_call_cmd action in order.
Confirmed via ldd that the shared libraries were being linked from the
/usr/local/lib directory instead of from the subproject directories.

Change-Id: I964508ef94f74e9d78753e38cf51b705d79a999c
Signed-off-by: Johnathan Mantey <johnathanx.mantey@intel.com>

show more ...


# 889ac26a 06-Aug-2024 George Liu <liuxiwei@ieisystem.com>

UT: disable code coverage support for autotools

Since lcov was removed in the previous commit [1], CI script
execution failed to support autotools projects (such as libmctp):
```
checking for genhtm

UT: disable code coverage support for autotools

Since lcov was removed in the previous commit [1], CI script
execution failed to support autotools projects (such as libmctp):
```
checking for genhtml... no
configure: error: To enable code coverage reporting you must have lcov installed
```

This commit only disables code coverage support for autotools-based
projects.

Refer: https://github.com/openbmc/openbmc-build-scripts/issues/37

[1]: https://gerrit.openbmc.org/c/openbmc/openbmc-build-scripts/+/72544

Signed-off-by: George Liu <liuxiwei@ieisystem.com>
Change-Id: Ib62a5f3092d8c6933f3b9ca00d08dbb38d91ce3a

show more ...


# 04770ccd 18-Jun-2024 Michal Orzel <michalx.orzel@intel.com>

unit-test: Support for valgrind on boost

When UTs, which are run under valgrind, utilize boost coroutines, there
might occur errors during stack switching. Boost has prepared an option
to suppress t

unit-test: Support for valgrind on boost

When UTs, which are run under valgrind, utilize boost coroutines, there
might occur errors during stack switching. Boost has prepared an option
to suppress these errors with build option `valgrind=on`, combined with
compile flag `BOOST_USE_VALGRIND` [1]. This patch implements these
options into boost package and CMake/Meson project configurations.

Tested:
On a change where CI are failing due to valgrind errors [2]. When using
container from this patch, these errors stop appearing and CI ends with
success.

[1] https://www.boost.org/doc/libs/1_82_0/libs/context/doc/html/context/stack/valgrind.html
[2] https://gerrit.openbmc.org/c/openbmc/jsnbd/+/59600/11

Change-Id: I183eaf7c15ac9cc2799f446fe7fb933d957fac21
Signed-off-by: Michal Orzel <michalx.orzel@intel.com>

show more ...


# 34b4f1cb 19-May-2024 Andrew Jeffery <andrew@codeconstruct.com.au>

scripts: unit-test: Make valgrind exit failure on error

By default valgrind exits with the exit status of the process under
examination. From the manual[1]:

> --error-exitcode=<number> [default: 0

scripts: unit-test: Make valgrind exit failure on error

By default valgrind exits with the exit status of the process under
examination. From the manual[1]:

> --error-exitcode=<number> [default: 0]
>
> Specifies an alternative exit code to return if Valgrind reported any
> errors in the run. When set to the default value (zero), the return
> value from Valgrind will always be the return value of the process
> being simulated. When set to a nonzero value, that value is returned
> instead, if Valgrind detects any errors. This is useful for using
> Valgrind as part of an automated test suite, since it makes it easy
> to detect test cases for which Valgrind has reported errors, just
> by inspecting return codes. When set to a nonzero value and Valgrind
> detects no error, the return value of Valgrind will be the return
> value of the program being simulated.

[1]: https://valgrind.org/docs/manual/manual-core.html#manual-core.options

The default value of 0 is not actually useful for CI, where we want it
to bubble up a failure if poor behavior is detected.

Change-Id: I6e7c56b9ccee5c8f9c5234df19ab84009868ff88
Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>

show more ...


# 8bf1ecd7 16-May-2024 Andrew Jeffery <andrew@codeconstruct.com.au>

scripts: unit-test: Constrain test setups to current project

self.package now reflects the top-level meson project name. Using this,
prevent incorrect propagation of configuration into subprojects u

scripts: unit-test: Constrain test setups to current project

self.package now reflects the top-level meson project name. Using this,
prevent incorrect propagation of configuration into subprojects using
the usual meson scope syntax.

Further, now that we're using the scope syntax, meson outputs a
different error message:

```
$ meson test --setup=stdplus:__likely_not_a_setup__ -C build __likely_not_a_test__
Unknown test setup 'stdplus:__likely_not_a_setup__'.
```

Adjust the regex that performs the setup error test.

Change-Id: Ia15c0406323f025fff318cb1c1e4a92605d19c96
Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>

show more ...


# fdfd8d48 15-May-2024 Andrew Jeffery <andrew@codeconstruct.com.au>

scripts: unit-test: Replace outdated timeout logic

Back in 2019 William added a new code-path for exploiting a meson
project's 'valgrind' test setup, if one existed[1]:

[1]: https://github.com/open

scripts: unit-test: Replace outdated timeout logic

Back in 2019 William added a new code-path for exploiting a meson
project's 'valgrind' test setup, if one existed[1]:

[1]: https://github.com/openbmc/openbmc-build-scripts/commit/49d4e594e8959cd8764

At the time, the behavior of `meson test -t 0 ...` was to immediately
terminate. This was useful in the context of testing whether a project
provided the a particular test setup, as we could invoke `meson test -t
0 --setup=<name>` without any significant impact on CI execution time.

However, as of meson 0.57.0 the behavior of `meson test -t 0`
changed[2]:

> test() timeout and timeout_multiplier value <= 0
>
> test(..., timeout: 0), or negative value, used to abort the test
> immediately but now instead allow infinite duration. Note that
> omitting the timeout keyword argument still defaults to 30s timeout.
>
> Likewise, add_test_setup(..., timeout_multiplier: 0), or meson test
> --timeout-multiplier 0, or negative value, disable tests timeout.

[2]: https://mesonbuild.com/Release-notes-for-0-57-0.html#test-timeout-and-timeout_multiplier-value-0

The consequence of the change is that the test for the existence of the
named setup in the project now executes the test suite with timeouts
disabled when the named setup is provided by the project at hand.

Further, having established that the named setup is supported by the
project, the script then executes the test suite _again_[^1].

A useful observation at this point is the the output from the following
set of commands, using stdplus[3] as an example:

```
$ meson test --setup=__likely_not_a_setup__ -C build __likely_not_a_test__
Test setup '__likely_not_a_setup__' not found from project 'stdplus'.
$ meson test --setup=valgrind -C build __likely_not_a_test__
ERROR: *:__likely_not_a_test__ test name does not match any test
```

[3]: https://github.com/openbmc/stdplus

Using an unlikely test name we make it likely that we error out in the
case where the named test setup is supported by the project. We use this
as a substitute for the old behavior of `-t 0`.

[^1]: Though at least it sets a timeout multiplier of 10, rather than
disabling the timeout.

Tested: Ran the CI container against:

- entity-manager, which does not define a 'valgrind' test setup
- stdplus, which does define a 'valgrind' test setup

Verified that `meson test` was invoked with `--wrapper valgrind` for
entity-manager, and `--setup valgrind` for stdplus.

Change-Id: I78090716dd2842e6f4485a69f353d15ca11b62d1
Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>

show more ...


# bf83a1b3 15-May-2024 Andrew Jeffery <andrew@codeconstruct.com.au>

scripts: unit-test: Derive package name from meson.build

The implementation for package name derivation implemented in
BuildSystem.__init__() simply takes the basename of the directory
containing th

scripts: unit-test: Derive package name from meson.build

The implementation for package name derivation implemented in
BuildSystem.__init__() simply takes the basename of the directory
containing the source code if another name isn't supplied.

For meson builds we can make a smarter choice, and the result is that
we can lift the requirement that the directory be named after the
project. This is helpful for some workflows where the CI container is
run locally.

By introspecting the build configuration we can extract the meson
project name. Defining the package name as the project name is useful
for meson command invocations. For example, the project name can be used
to specify constraints on build variables (`-D<project>:werror=false`)
and test setups (`--setup=<project>:valgrind`), preventing configuration
from incorrectly propagating into other (sub)projects.

Override the package name once the build configuration is available.

Change-Id: I52dc03253a54589cba0ff2fae5ddba2a74d458ba
Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>

show more ...


# ac9c9c73 07-Dec-2023 Lei YU <yulei.sh@bytedance.com>

unit-test: meson: Use clang-tidy-fix

In meson 1.3.0 `clang-tidy-fix` target is added if `.clang-tidy` file
exists. This could be used to run clang-tidy with the fixes applied to
the source code.

Ch

unit-test: meson: Use clang-tidy-fix

In meson 1.3.0 `clang-tidy-fix` target is added if `.clang-tidy` file
exists. This could be used to run clang-tidy with the fixes applied to
the source code.

Change the unit-test script to use `clang-tidy-fix` for meson projects.

Tested: Manually verify in a meson proejct that the `clang-tidy` check
fixes the code if issues are found.

Signed-off-by: Lei YU <yulei.sh@bytedance.com>
Change-Id: Ic6e1c6253b7fba075c26d9aad607854b49be9b23

show more ...


# 08fa1d5a 29-Nov-2023 William A. Kennington III <wak@google.com>

scripts/unit-test.py: Support meson.options file

We are now using the new name supported in meson 1.1+ and we need to
parse the options at the new location if it exists.

Change-Id: If07230911b5b3bc

scripts/unit-test.py: Support meson.options file

We are now using the new name supported in meson 1.1+ and we need to
parse the options at the new location if it exists.

Change-Id: If07230911b5b3bccd7792ec5dd3e3fd4bf40aef2
Signed-off-by: William A. Kennington III <wak@google.com>

show more ...


# b9e07122 12-Jul-2023 Patrick Williams <patrick@stwcx.xyz>

unit-test: add meson version check for C++23

We can start using C++23 in Meson, but it requires meson 1.1.1 or
later. Add the meson_version check in unit-test just like we've
done in the past for C

unit-test: add meson version check for C++23

We can start using C++23 in Meson, but it requires meson 1.1.1 or
later. Add the meson_version check in unit-test just like we've
done in the past for C++20.

Tested:

Changed sdbusplus to only have 'cpp_std=c++23' while using older
meson_version and experienced the expected exception.

```
Exception: C++23 support requires specifying in meson.build: meson_version: '>=1.1.1'
```

Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
Change-Id: I3d355f5176fb1874b7301ab995e96f22dbd6b429

show more ...


# 9d43ecfe 24-May-2023 Andrew Jeffery <andrew@aj.id.au>

unit-test: Increase available debug information for test builds

Configuring `-Og` helps ensure `abi-dumper` has all the information it
would like for ABI analysis.

```
...
[18/39] Generatin

unit-test: Increase available debug information for test builds

Configuring `-Og` helps ensure `abi-dumper` has all the information it
would like for ABI analysis.

```
...
[18/39] Generating abi-dump with a custom command
Detect public symbols
Reading debug-info
WARNING: incompatible build option detected: -O0 (required -Og for better analysis)
...
```

Change-Id: Ia4d2add17a1e65bb480cb7003597af62c8e47bc2
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>

show more ...


# 71924fdb 12-Apr-2023 Andrew Jeffery <andrew@aj.id.au>

unit-test: Make UBSAN kill tests

Continuing to exploit the runtime library means we get useful
diagnostics printed rather than just the application generating a core.

Change-Id: I0b93e61bbca48eb5a7

unit-test: Make UBSAN kill tests

Continuing to exploit the runtime library means we get useful
diagnostics printed rather than just the application generating a core.

Change-Id: I0b93e61bbca48eb5a79ba6fa9228431d36504f64
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>

show more ...


# cebaea28 12-Apr-2023 Patrick Williams <patrick@stwcx.xyz>

unit-test: add meson version check for get_variable

Some repositories are using the newer `get_variable` call in meson
without a keyword argument. This requires meson 0.58 or later. I've
contribut

unit-test: add meson version check for get_variable

Some repositories are using the newer `get_variable` call in meson
without a keyword argument. This requires meson 0.58 or later. I've
contributed fixes for all repositories under the
`meson_deprecated_pkgconfig` topic and so am also adding a CI catch
to prevent future regressions.

Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
Change-Id: I9465c3946825ec96d0c934635685e85d74fdf4ee

show more ...


# 688f837a 02-Mar-2023 Brad Bishop <bradleyb@fuzziesquirrel.com>

cppcheck: enable inline-suppr

Allow inline suppression of cppcheck errors for special cases. Some
example use cases might be:

- suppress accessMoved in a unit test for a move constructor (ensuring

cppcheck: enable inline-suppr

Allow inline suppression of cppcheck errors for special cases. Some
example use cases might be:

- suppress accessMoved in a unit test for a move constructor (ensuring
the moved from object is in the expected state).
- suppress noExplicitConstructor for RAII types where implicit
conversion is intentional and desired.

Change-Id: I560d780fdf9266dc54662a9eeb6ed6986fc271a8
Signed-off-by: Brad Bishop <bradleyb@fuzziesquirrel.com>

show more ...


# 1eb1994b 10-Feb-2023 Ed Tanous <edtanous@google.com>

Run clang-tidy in meson

Meson has built in functionality for running clang-tidy. It improves on
run-clang-tidy because it will also run each header file individually,
rather than relying on their #

Run clang-tidy in meson

Meson has built in functionality for running clang-tidy. It improves on
run-clang-tidy because it will also run each header file individually,
rather than relying on their #inclusion into a src file, which can find
far more missing #includes, and seems to find more issues in complex
source files (unclear why).

Tested: I've walked through all the repos that have a .clang-tidy, and
I've systematically fixed the issues, so hopefully this change has no
impact. I have yet to see this cause any functional impact.

Signed-off-by: Ed Tanous <edtanous@google.com>
Change-Id: I62520056192d876938ddab4d7cdafc954fa1806d

show more ...


# 87ab5705 13-Jan-2023 Michael Shen <gpgpgp@google.com>

unit-test: support install process in cmake

This change allows cmake-based project to install the
executable/library/configuration to the right directory.

Tested:
Manually run the commands below in

unit-test: support install process in cmake

This change allows cmake-based project to install the
executable/library/configuration to the right directory.

Tested:
Manually run the commands below in the docker.
```
$ sudo cmake --install .
-- Install configuration: ""
-- Installing: /usr/local/lib/xxx.so
-- Installing: /usr/local/include/xxx.h
-- Installing: /usr/local/bin/xxx_tool
```

Change-Id: Ica9f0c26c57baca5d46067c1bb55ecccc2d8fc58
Signed-off-by: Michael Shen <gpgpgp@google.com>

show more ...


# 29e02313 19-Dec-2022 Ed Tanous <edtanous@google.com>

Make clang-tidy projects compile on clang

Compiling individual repos on clang gives us an extra set of checks, and
ensures that we are coding to the c++ standard, and not to gcc
specifics. In pract

Make clang-tidy projects compile on clang

Compiling individual repos on clang gives us an extra set of checks, and
ensures that we are coding to the c++ standard, and not to gcc
specifics. In practice, a lot of the repos have compiled against clang
for a while, but leads to maintainers jumping in from time to time to
fix the clang build with seemingly minor changes that are better caught
at review time.

This commit causes the clang build (created as part of the tidy checks)
to actually compile, which can find issues like
https://gerrit.openbmc-project.xyz/c/openbmc/bmcweb/+/51346 that clang
finds, but gcc does not (or allows silently).

I walked through every repo I'm aware of that are relying on clang-tidy,
and made sure that they compile with clang. bmcweb, dbus-sensors, and
entity-manager have patchsets in review to resolve the minor issues,
that should be merged before this.

sdeventplus builds with clang as-is.

Tested:
Compiled repos above against clang with the aforementioned commits, and
build passed.

Signed-off-by: Ed Tanous <edtanous@google.com>
Change-Id: I310f9aebc75fe4bc9645c4c961ca0caf8f94b4d5

show more ...


1234567