mirror of
https://github.com/Mbed-TLS/mbedtls.git
synced 2025-04-17 11:43:37 +00:00
64 lines
2.6 KiB
Bash
64 lines
2.6 KiB
Bash
# components.sh
|
|
#
|
|
# Copyright The Mbed TLS Contributors
|
|
# SPDX-License-Identifier: Apache-2.0 OR GPL-2.0-or-later
|
|
|
|
# This file contains the test components that are executed by all.sh
|
|
|
|
# The functions below are named as follows:
|
|
# * component_XXX: independent components. They can be run in any order.
|
|
# * component_check_XXX: quick tests that aren't worth parallelizing.
|
|
# * component_build_XXX: build things but don't run them.
|
|
# * component_test_XXX: build and test.
|
|
# * component_release_XXX: tests that the CI should skip during PR testing.
|
|
# * support_XXX: if support_XXX exists and returns false then
|
|
# component_XXX is not run by default.
|
|
|
|
# Each component must start by invoking `msg` with a short informative message.
|
|
#
|
|
# Warning: due to the way bash detects errors, the failure of a command
|
|
# inside 'if' or '!' is not detected. Use the 'not' function instead of '!'.
|
|
#
|
|
# Each component is executed in a separate shell process. The component
|
|
# fails if any command in it returns a non-zero status.
|
|
#
|
|
# The framework in all.sh performs some cleanup tasks after each component.
|
|
# This means that components can assume that the working directory is in a
|
|
# cleaned-up state, and don't need to perform the cleanup themselves.
|
|
# * Run `make clean`.
|
|
# * Restore `include/mbedtls/mbedtls_config.h` from a backup made before running
|
|
# the component.
|
|
# * Check out `Makefile`, `library/Makefile`, `programs/Makefile`,
|
|
# `tests/Makefile` and `programs/fuzz/Makefile` from git.
|
|
# This cleans up after an in-tree use of CMake.
|
|
#
|
|
# The tests are roughly in order from fastest to slowest. This doesn't
|
|
# have to be exact, but in general you should add slower tests towards
|
|
# the end and fast checks near the beginning.
|
|
|
|
|
|
################################################################
|
|
#### Build and test many configurations and targets
|
|
################################################################
|
|
|
|
################################################################
|
|
#### Basic checks
|
|
################################################################
|
|
|
|
#
|
|
# Test Suites to be executed
|
|
#
|
|
# The test ordering tries to optimize for the following criteria:
|
|
# 1. Catch possible problems early, by running first tests that run quickly
|
|
# and/or are more likely to fail than others (eg I use Clang most of the
|
|
# time, so start with a GCC build).
|
|
# 2. Minimize total running time, by avoiding useless rebuilds
|
|
#
|
|
# Indicative running times are given for reference.
|
|
|
|
################################################################
|
|
#### Build and test many configurations and targets
|
|
################################################################
|
|
|
|
|