✨ Features ************ Component Report ---------------- To support the :ref:`component ` development, SPL Core provides features to: - document the component behavior - see :ref:`How to create a component detail design ` - test the component behavior - see :ref:`How to create a component test cases ` - generate component report with full traceability between documentation, code and tests - see :ref:`Component relevant CMake Targets ` Variant Report -------------- To support the :ref:`variant ` development, SPL Core provides features to: TODO: add variant report description Multi-Binary Support -------------------- To support variants with related multiple binaries, SPL Core provides the possibility to define multiple executables and specify to which executable to add a component. The use case can be building the application and its corresponding bootloader as two separate binaries for a variant. For this, one can specify the target executable when using the `spl_add_component()` and `spl_add_named_component()` macros. Example of defining multiple executables: .. code-block:: cmake :caption: parts.cmake # Components added to the default executable created automatically by spl_core spl_add_component(src/compA) spl_add_component(src/compB) # Add new executable add_executable(bootloader) # Bootloader-specific components spl_add_component(src/compA bootloader) spl_add_component(src/boot bootloader) Pypeline Steps -------------- Spl-Core provides the step CollectPRChanges for `Pypeline `_ to be used in an SPL. This step fetches the list of changed files inside a pull request (PR), which can then be used for granular quality gate checks inside an SPL. To use this step, you need to add it to your pypeline.yaml file as follows: .. code-block:: yaml ... - step: CheckCIContext module: pypeline_semantic_release.steps - step: CollectPRChanges module: spl_core.steps.collect_pr_changes ... It is mandatory that the CheckCIContext step is executed before the CollectPRChanges step.