2.8 (2026-02-22)

Support for Waf package types

Introduction of the waf package type. This new package type allow a developer to easily invoke Waf targets at various stages, without needing invoke these tools inside a scripts package.

Introduce package configurable maximum job limit

This release introduces support for LIBFOO_MAX_JOBS, allowing a specific package to configure maximum number of jobs it should use for a build.

While LIBFOO_FIXED_JOBS somewhat served this capability before, its use was tailored for restricting packages to a single job only. If a project could use a subset of jobs to run, there was no easy way to configure this. This could be tricky for packages which might have memory requirements per job unit which cannot be provided by a builder.

If a build environment has tens to hundreds of cores, but a developer knows a package can only run around four jobs for package, they may tailor a maximum count as follows:

LIBFOO_MAX_JOBS = 4

In addition to limiting job counts, the max-jobs value also accepts negative values. This can be used to hint to using N-less jobs than the detected amount. For example, if a package is best to use all cores but one for a build, a package may define negative one as follows:

LIBFOO_MAX_JOBS = -1

Project configuration revisions options

Packages will typically define revisions to fetch through LIBFOO_VERSION and LIBFOO_REVISION options. This follows the idea of containing package-specific information inside a package’s definition. However, developers may instead wish to manage fixed revisions in a single location due to their possible volatility when compared to other options.

Developers looking for the convenience of managing revisions in a single location can do so by defining a revisions project configuration option. For example:

revisions = {
    'libfoo': 'libfoo-v2.1',
    'myapp': '1.0.0',
}

For the package libfoo, the its LIBFOO_REVISION will be configured to libfoo-v2.1. As well as the package myapp will have its MYAPP_REVISION configured to 1.0.0.

Support skipping integrity checks for development-marked packages

Support has been added to allow developers to skip integrity checks for specific packages when in development mode.

A package definition will typically have hashes defined for static resources to verify their contents. While this is desired approach for standard packages, a developer which defines a development-variant package when testing bleeding edge sources can experience fetch failures since development assets will have a mismatched hash. A developer can workaround this by appending additional hashes for a package, but this can remove the flexibility of acquiring bleeding edge assets for an internal package.

To workaround this scenario, the package configuration LIBFOO_DEVMODE_SKIP_INTEGRITY_CHECK has been introduced. Consider this example:

LIBFOO_SITE = {
    DEFAULT_SITE: 'https://pkgs.example.com/releases/libfoo-1.2.3.tar.gz',
    'test': 'https://staging.example.org/nightly/libfoo-latest.tar.gz',
}

LIBFOO_DEVMODE_SKIP_INTEGRITY_CHECK = True

This package defines a default and development site for a package resource. If the package defined a hash file (libfoo.hash), the hash definition would typically require explicit hashes for both libfoo-1.2.3.tar.gz and libfoo-latest.tar.gz. However, if LIBFOO_DEVMODE_SKIP_INTEGRITY_CHECK is set, when running with in a test development mode, no hashes are required for the latest artifact.

SPDX license database updated

The internally managed copy of the SPDX license identifiers has been updated to the most recent version (v3.28).