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 10 Next »

Hierarchy

Description

List of the top-level directories:

DirectoryContent
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.

Categories

All components were originally laid out in one-level but are being reorganized by categories.

Whenever a component is added or updated, it should be placed under the directory indicates by the Categories layout.

Meta-packages

These components do not deliver any file content but define groups of software or logic to manage installation/removal/deprecation of packages.

They are all located within the directory 'components/meta-packages'.

Component structure

Files

NameContent
Makefile 
*.license 
*.p5m 
history 
manifests/ 
patches/ 
test/ 

 

Makefile targets

TargetFunctionWhen to use it?
clobber  
clean  
env-prep  
prep  
build  
install  

sample-manifest

  

pre-publish

  
publish  
REQUIRED_PACKAGES  

 

Testing

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 shared-macros.mk: 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'.

Comparison

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:

COMPONENT_TEST_MASTER =		$(COMPONENT_TEST_RESULTS_DIR)/results-all.master

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'.

Example:

Autotools

Only test results are retained:

COMPONENT_TEST_TRANSFORMS += \
        '-n ' \
        '-e "/TOTAL:/p" ' \
        '-e "/SKIP:/p" ' \
        '-e "/PASS:/p" ' \
        '-e "/FAIL:/p" ' \
        '-e "/ERROR:/p" '
CTest

Timestamps should be removed:

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

 

 

Recommendations

A list of recommendations for maintainers is listed at Best Practices.

IPS manifests

Manifest generation

Package actions

Content

ActionDefinitionUsage
file  
dir  
link  
hardlink  
user  
group  
driver  

Metadata

ActionDefinitionUsage
set  
depend  
license  
signature  

 

Transforms

Transforms are mainly used to set default attributes to files like ownership and permissions.

They are defined in oi-userland's transforms directory.

Examples

Set mode for binary executables:

<transform file path=usr/lib/$(MACH64)/e.+/utils/.+ -> default mode 0555>

 

Variants and facets

Incorporations

Linting

Package repositories

On-disk repositories

Remote repositories

Working with a pkg(5) server

  • No labels