• Diff for "BuildProfileSpec"

Document status

Preliminary support of this spec was implemented in

Problem description

For some compilation scenarios it is required to build-depend on a different set of binary packages than specified in the Build-Depends line. The two most important scenarios are:

• Bootstrapping (for breaking build dependency cycles) and

• Cross building (for source packages having different build dependencies during cross building than during native building)

This specification describes two possible extensions of the Build-Depends field syntax. These extensions allow the marking of build dependencies as being needed or not needed when a specific build profile is activated. It also defines a new field called "Build-Profiles" which aids in marking binary packages as being built or not built whilst a certain build profile is activated or having been built with a certain set of build profiles activated.

Build profiles can be activated by setting the environment variable DEB_BUILD_PROFILES or by using the -P option with dpkg-buildpackage (or -o Apt::Build-Profiles for apt, or --profiles in sbuild). More than one build profile can be activated at a time. Multiple profiles are specified by separating them with commas in commandline arguments and by separating them with spaces in the DEB_BUILD_PROFILES environment variable. The initial profile names are "stage1", "stage2", "nocheck", "nobiarch" and "cross". Other possibilities are "nodoc" or "embedded".

Build-Depends syntax extension

An example demonstrating the build profile syntax:

Build-Depends: foo (>= 1.0) [i386 arm] <!profile.stage1 !profile.cross>, bar

This specification introduces a new pair of brackets (using < as the opening and > as the closing bracket) to be used after the architecture qualification list. Just as in the architecture qualification list the < and > brackets enclose a space separated list of terms called a restriction list.

Every term in the restriction list follows the following regular expression:

([a-z][a-z0-9-]*)\.([a-z][a-z0-9-]*)

The first group is called a namespace. The namespace "profile" is used to support build profiles and is the only allowed namespace for now. By introducing additional namespaces, this syntax can later be extended for other uses besides build profiles (for example an "arch" namespace can be introduced). No other namespace besides "profile" exists yet but it is forbidden to mix different namespaces within one restriction list. The second group is called a label and specifies the profile name.

Terms can be negated by using an exclamation mark as a prefix. In contrast to the architecture qualification list, positive and negative terms are allowed to be mixed. The semantics of a restriction list are computed as follows:

• one or more profiles can be activated at the same time (by commandline argument or environment variable)
• for each dependency, the restriction list is processed from left to right
• if a negated term is encountered and the specified profile is set, the build dependency is dropped and processing of the list stops
• if a positive term is encountered and the specified profile is set, then the build dependency is kept and processing of the list stops
• if no profile is set for any term in the restriction list and at least one term in the restriction list is negated then keep the build dependency, otherwise drop the build dependency

Above rules express the same semantics as architecture restrictions if positive and negative terms are not mixed. If positive and negative terms are mixed (and only then) then the order of the terms in the restriction list matters. The following table illustrates the implication of the above rules. Each cell indicates whether or not the dependency foo is dropped with a certain value of DEB_BUILD_PROFILES.

Future extensions

• The syntax could be extended to allow more than one <> block

• It could also be allowed to allow architecture names under the "arch" namespace within a <> block.

• It could be allowed to mix different namespaces within a <> block

The Build-Profiles field

In debian/control binary package stanzas, the content of the Build-Profiles field specifies the (unordered) list of build profiles for which that binary package does or does not build. This list can either be all positive or all negative. Entries are negated by using an exclamation mark as a prefix.

Build-Profiles: !cross !stage1

If a binary package stanza in a debian/control file does not contain a Build-Profiles field, then it implicitly means that it builds with all build profiles.

A binary package must offer the exact same functionality for all profiles with which it builds including no activated profile at all (if it builds in that case). Otherwise a package depending on that binary package might not find the functionality it expects it to provide. This means that if necessary binary packages have to be split or that a source package has to be built in two stages.

The Built-For-Profiles field

In *.changes and Packages files, the content of the Built-For-Profiles field specifies the list of build profiles for which that binary or source package was built.

The DEB_BUILD_PROFILES environment variable

The DEB_BUILD_PROFILES environment variable contains a space separated unordered list of activated profiles. The content of this variable must be honored by all tools involved in package compilation. Here an example for debian/rules (enabling sql for any build except stage1 profile - notice the negated test):

ifneq ($(filter stage1,$(DEB_BUILD_PROFILES)),)
    DH_OPTIONS += -Nlibdb5.1-sql # not needed with debhelper (>= 9.20140227)
    CONFIGURE_SWITCHES += --disable-sql
else
    CONFIGURE_SWITCHES += --enable-sql
endif

Discussion