Child pages
  • 2. Overview of the Build System
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Next »



List of the top-level directories:

archivesSource tarballs downloaded for building components.
componentsHierarchy of directories containing packaging recipes.
docDocumentation of the build system.
make-rulesMakefile rules used by components.
templatesTemplates of component Makefile for different types of build toolchains.
toolsScripts used by the build system.
transformsDefault rules used for the generation of IPS packages.



Component structure


Makefile targets


The testing framework can be used to make build reproducible and ensure that no regression is introduced when components are updated.

Support for the 'test' target should be ideally added to any component at creation or at update if it is not the case.

Makefile variables 'COMPONENT_TEST_*' affecting the execution of the test suite are declared in most of these variables need not be changed.

Test run

After the component is built and installed test suites can be run using 'gmake test' if the 'test' target is declared in the component Makefile.

Example: tests for 32-bit and 64-bit versions

test target
test:	$(TEST_32_and_64)

The environment of the test suite can be changed with the variable 'COMPONENT_TEST_ENV'.


If a master result file exists in the component test directory, the output produced by the test run is compared against master test results.

The default directory for master test results is 'test' as defined in the variable 'COMPONENT_TEST_RESULTS_DIR'.

Default names for the master files are defined in the variable 'COMPONENT_TEST_MASTER' as:

  1. results-32.master,
  2. results-64.master.

and correspond to 32-bit and 64-bit builds respectively.

The first time a master result file is added to the component, an empty file should be created prior to running 'gmake test' to trigger the comparison stage.

Example: initial creation of a master results file for a 32-bit build

$ mkdir test
$ touch test/results-32.master
$ gmake test

The comparison will fail as the master results file is empty: the actual test output should be copied to the test result directory (do not forget to commit the newly created file).

$ cp build/test/i86/results-32.snapshot test/results-32.master

If the results are architecture independent, the variable may be set to:


Test results may be processed to retain relevant machine-independent output only.

Transforms of the output are controlled by two variables:

  1. the tool used for the transform is set by 'COMPONENT_TEST_TRANSFORMER' (default: GNU sed),
  2. the rules defined in 'COMPONENT_TEST_TRANSFORMS'.



Only test results are retained:

        '-n ' \
        '-e "/TOTAL:/p" ' \
        '-e "/SKIP:/p" ' \
        '-e "/PASS:/p" ' \
        '-e "/FAIL:/p" ' \
        '-e "/ERROR:/p" '

Timestamps should be removed:

COMPONENT_TEST_TRANSFORMS+= '-e "s/[0-9. ]*sec//g"'




IPS manifests

Manifest generation

Package actions


Variants and facets



Package repositories

On-disk repositories

Remote repositories

Working with a pkg(5) server

  • No labels