I think people might be reading differences into 'if' and 'depends on'
that aren't there, like maybe 'if' being needed to "hide" a symbol,
while 'depends on' just adds a dependency.
There are no differences between 'if' and 'depends on'. 'if' is just a
shorthand for 'depends on'. They work the same when it comes to creating
implicit menus too.
The way symbols get "hidden" is through their dependencies not being
satisfied ('if'/'depends on' get copied up as a dependency on the
prompt).
Since 'if' and 'depends on' are the same, an 'if' with just a single
symbol in it can be replaced with a 'depends on'. IMO, it's best to
avoid 'if' there as a style choice too, because it confuses people into
thinking there's deep Kconfig magic going on that requires 'if'.
Going for 'depends on' can also remove some nested 'if's, which
generates nicer symbol information and docs, because nested 'if's really
are so simple/dumb that they just add the dependencies from both 'if's
to all symbols within.
Replace a bunch of single-symbol 'if's with 'depends on' to despam the
Kconfig files a bit and make it clearer how things work. Also do some
other minor related dependency refactoring.
The replacement isn't complete. Will fix up the rest later. Splitting it
a bit to make it more manageable.
(Everything above is true for choices, menus, and comments as well.)
Detected by tweaking the Kconfiglib parsing code. It's impossible to
detect after parsing, because 'if' turns into 'depends on'.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
154 lines
5.0 KiB
Plaintext
154 lines
5.0 KiB
Plaintext
# Copyright (c) 2016 Intel Corporation
|
|
# SPDX-License-Identifier: Apache-2.0
|
|
|
|
menu "Testing"
|
|
|
|
source "subsys/testsuite/ztest/Kconfig"
|
|
|
|
config TEST
|
|
bool "Mark project as a test"
|
|
# For tests, store thread names in binary and dump them on crash to
|
|
# ease debugging.
|
|
select THREAD_NAME
|
|
help
|
|
Mark a project or an application as a test. This will enable a few
|
|
test defaults.
|
|
|
|
config TEST_SHELL
|
|
bool "Enable various shells for testing"
|
|
select GPIO_SHELL if GPIO
|
|
help
|
|
Enable various platform and driver related shells for testing.
|
|
|
|
config TEST_EXTRA_STACKSIZE
|
|
int "Test function extra thread stack size"
|
|
default 2048 if COVERAGE_GCOV
|
|
default 768 if XTENSA
|
|
default 0
|
|
help
|
|
Additional stack for tests on some platform where default is not
|
|
enough.
|
|
|
|
config HAS_COVERAGE_SUPPORT
|
|
bool
|
|
help
|
|
The code coverage report generation is only available on boards
|
|
with enough spare RAM to buffer the coverage data, or on boards
|
|
based on the POSIX ARCH.
|
|
|
|
config COVERAGE
|
|
bool "Create coverage data"
|
|
depends on HAS_COVERAGE_SUPPORT
|
|
help
|
|
This option will build your application with the -coverage option
|
|
which will generate data that can be used to create coverage reports.
|
|
For more information see
|
|
https://docs.zephyrproject.org/latest/guides/coverage.html
|
|
|
|
config COVERAGE_GCOV
|
|
bool "Create Coverage data from hardware platform"
|
|
default y
|
|
depends on COVERAGE
|
|
depends on !NATIVE_APPLICATION
|
|
help
|
|
This option will select the custom gcov library. The reports will
|
|
be available over serial. This serial dump can be passed to
|
|
gen_gcov_files.py which creates the required .gcda files. These
|
|
can be read by gcov utility. For more details see gcovr.com .
|
|
|
|
config COVERAGE_DUMP
|
|
bool "Dump coverage data on exit"
|
|
depends on COVERAGE_GCOV
|
|
help
|
|
Dump collected coverage information to console on exit.
|
|
|
|
config TEST_USERSPACE
|
|
bool "Indicate that this test exercises user mode"
|
|
help
|
|
This option indicates that a test case puts threads in user mode,
|
|
and that the build system will [override and] enable USERSPACE
|
|
if the platform supports it. It should be set in a .conf file on
|
|
a per-test basis and is not meant to be used outside test cases.
|
|
Tests with this option should also have the "userspace" filtering
|
|
tag in their testcase.yaml file.
|
|
|
|
The userspace APIs are no-ops if userspace is not enabled, so it is
|
|
OK to enable this even if the test will run on platforms which do
|
|
not support userspace. The test should still run on those platforms,
|
|
just with all threads in supervisor mode.
|
|
|
|
If a test *requires* that userspace be enabled in order to
|
|
pass, CONFIG_ARCH_HAS_USERSPACE should be filtered in its
|
|
testcase.yaml.
|
|
|
|
config TEST_LOGGING_DEFAULTS
|
|
bool "Enable test case logging defaults"
|
|
depends on TEST
|
|
select LOG
|
|
select LOG_MINIMAL
|
|
default y
|
|
help
|
|
Option which implements default policy of enabling logging in
|
|
minimal mode for all test cases. For tests that need alternate
|
|
logging configuration, or no logging at all, disable this
|
|
in the project-level defconfig.
|
|
|
|
config TEST_ENABLE_USERSPACE
|
|
bool
|
|
depends on TEST_USERSPACE
|
|
depends on ARCH_HAS_USERSPACE
|
|
select USERSPACE
|
|
select DYNAMIC_OBJECTS
|
|
default y
|
|
help
|
|
This hidden option implements the TEST_USERSPACE logic. It turns on
|
|
USERSPACE when CONFIG_ARCH_HAS_USERSPACE is set and the test
|
|
case itself indicates that it exercises user mode via
|
|
CONFIG_TEST_USERSPACE.
|
|
|
|
config TEST_USERSPACE_WITHOUT_HW_STACK_PROTECTION
|
|
bool "Run User Mode tests without additionally enabling stack protection"
|
|
depends on TEST_ENABLE_USERSPACE
|
|
default y if SOC_SERIES_KINETIS_KE1XF
|
|
help
|
|
A HW platform might not have sufficient MPU/MMU capabilities to support
|
|
running all test cases with User Mode and HW Stack Protection features
|
|
simultaneously enabled. For this platforms we execute the User Mode-
|
|
related tests without enabling HW stack protection.
|
|
|
|
config TEST_HW_STACK_PROTECTION
|
|
bool "Enable hardware-based stack overflow detection if available"
|
|
depends on ARCH_HAS_STACK_PROTECTION
|
|
depends on TEST
|
|
select HW_STACK_PROTECTION
|
|
default y if !TEST_USERSPACE_WITHOUT_HW_STACK_PROTECTION
|
|
help
|
|
This option will enable hardware-based stack protection by default
|
|
for all test cases if the hardware supports it.
|
|
|
|
config TEST_FLASH_DRIVERS
|
|
bool "Test flash drivers"
|
|
depends on BOARD_QEMU_X86
|
|
select FLASH_HAS_DRIVER_ENABLED
|
|
select FLASH_HAS_PAGE_LAYOUT
|
|
help
|
|
This option will help test the flash drivers. This should be enabled
|
|
only when using qemu_x86.
|
|
|
|
config TEST_ARM_CORTEX_M
|
|
bool
|
|
depends on CPU_CORTEX_M
|
|
default y
|
|
select ARM_SECURE_BUSFAULT_HARDFAULT_NMI if ARM_SECURE_FIRMWARE
|
|
help
|
|
ARM Cortex-M configuration required when testing.
|
|
|
|
Currently, this option is only utilized, to force routing
|
|
BusFault, HardFault, and NMI exceptions to Secure State,
|
|
when building a Secure ARMv8-M firmware. This will allow
|
|
the testing suite to utilize these exceptions, in tests.
|
|
Note that by default, when building with ARM_SECURE_FIRMWARE
|
|
set, these exceptions are set to target the Non-Secure state.
|
|
|
|
endmenu
|