Boost Clone

This action clones the Boost source directory, attempting to get it from the cache first. Only the specified modules are cloned and cached.

This is usually the next step in your workflow after setting up a C++ compiler with Setup C++ or installing other dependencies with Install Packages.

Cloning boost is useful when one wants the always use the latest version of boost in a library or is writing a boost proposal. For other use cases, individual boost modules can be fetched with vcpkg in Install Packages or directly included in a package manager manifest.

Besides the explicitly specified list of modules, the action can also scan directories for boost dependencies to implicitly determine what modules should be cloned.

The union of the implicitly and explicitly specified modules is cloned. Caching is based only on these dependencies.

For a project with about 5 boost dependencies, caching saves about 4 minutes in the workflow. When there’s no cache, the scanning scripting saves us about 3 minutes.

Next steps

After cloning boost modules for your C++ project, the next step in your workflow should usually be CMake Workflow. If you are developing a Boost library, it is also usual for the next step to be the B2 Workflow.

Example

steps:
- name: Clone Boost.Variant2
  uses: alandefreitas/cpp-actions/boost-clone@v1.8.7
  id: boost-clone
  with:
    branch: master
    modules: variant2

Input Parameters

Parameter

Description

Default

boost-dir

The boost directory. The default value assumes boost is in-source.

branch

Branch of the super-project.

master

patches

Libraries used to patch the boost installation. ⚠️ This parameter is required.

modules

The boost submodules we need to clone.

modules-scan-paths

Additional modules subdirectory to scan; can be repeated.

modules-exclude-paths

Additional modules subdirectory to scan; can be repeated.

test

scan-modules-dir

An independent directory we should scan for boost dependencies to clone.

scan-modules-ignore

List of modules that should be ignored in scan-modules.

cache

Cache boost source directory.

The cache key will include the boost hash, the modules hash and the patch hashes. When using the cache, the action will not scan for dependencies. This means that if a transitive dependency is updated, the cache will not be invalidated.

Note that the cache only includes the source directory and will be reused by other environments. This means binaries should not be included in the boost directory.

When testing a boost library, this source directory should be moved to another location before it’s the tests are built.

true

optimistic-caching

If this option is set to true, the cache key will not include the main boost super-project hash in the cache key. The key will only include the hash of direct module dependencies and patches in the cache key.

This means that if this option is true and transitive module dependencies are updated, the cache will not be invalidated until transitive dependencies are updated or the current cache expires.

On the other hand, if this option is set to false, the cache might be invalidated if unrelated modules in the super-project are updated.

false

trace-commands

Trace commands executed by the workflow.

false

Outputs

Output

Description

boost-dir

The absolute path to the boost source files.