CMake Build Artifact Management Specification

This high level specification describes how CMake can support a feature crucial to our development organization, namely the ability to organize, build and manage reusable binary components (aka "artifacts").

This feature exists for the Java build system "Maven" and is a central piece for any large scale java development. The idea is to port this feature for use with non-java projects.

See also: http://vtk.org/Bug/view.php?id=8471

High Level Specification

We have an artifact server. This can be any old service that accepts a PUT and a GET. This is where we store the single file representation of an artifact (aka "zipfile", "package", "tarball", "rpm", "deb"....).

Artifacts are probably best created via the existing CPack code. The main difference between the existing packages and an artifact are the inclusion of a CMake fragment which contains:

• Name of the artifact
• Version
• Platform / Generator
• Dependencies to other artifacts.

The definition of that metadata is within the project generating the package containing the artifact.

The location and the rules for mapping artifact names, versions and platform ids to artifact server URLs can be part of a project definition, or can be set globally.

The existence of that project within the current CMake run indicates that the artifact is to be built, not downloaded. A successful build may upload the artifact to the artifact server.

The absence of a project within the current CMake run indicates that the artifact is to be downloaded and installed. The CMake fragment in the package is then included in the current CMake run and recursively resolved. Should the desired version and platform/generator for a specific artifact not exist, then build stops with an error.