Defining Your Build

2 minute read

Before using Accelerator, precisely define which components go into your build. Generally, a build has three input types:


Build Sources

Build sources include all compiled or packaged files to build your product. For example, these sources include:

  • Intermediate files generated during the build (for example, headers or IDL files)

  • Makefiles and scripts that control the build

  • Third-party source files read during the build

  • Any file read by the build in source control

Build Tools

Tools used to create build output include make, compilers, linkers, and anything else operating on the sources during the build:

  • Executable post-process tools (for example, strip )

  • Static analyzers (for example, lint ) if they run as part of the build

  • Packaging tools (for example, tar or zip )

Sometimes the distinction between sources and tools is blurred. Consider these examples:

  • A utility executable compiled from your sources during the build, run during later steps, but not part of final output

  • Header source files that are part of the compiler (for example, stdio.h) or a third-party package, but not under source control

In this context, sources are those files that might change from one build to the next. Thus, a utility executable compiled from your sources as part of the build is considered a source.

By contrast, tools change infrequently—tools are often configured once and served from a central location (for example, an NFS share). A standard header such as stdio.h is usually considered part of the tool suite.

The distinction between inputs that can change between builds (sources) and inputs that can safely be assumed to be constant (tools) becomes important when configuring Accelerator virtualization.

Build Environment

Your operating system environment is an essential part of your build. The operating system is easy to overlook because the environment usually is configured once per host and then ignored as long as builds function normally. But when a build is distributed across a shared cluster, it is important to identify which parts of the operating system could affect the build. Some inputs to consider include:

  • User environment variables

  • System registry (Windows only)

  • Operating system version (including patches or service packs)

  • User account and user permissions

  • Host-specific attributes (for example, machine name, network configuration)

For each of these inputs, consider what impact (if any) they will have on the build.

Generally, some environment variables require correct settings for a build (for example, PATH or variables that specify output architecture or source/output file locations).

Another common example of how the operating system can affect the build occurs with the use of tools that require license management. If a tool license (for example, a compiler) is host-locked or it requires contacting a license server to operate, ensure the compiler on the host can acquire the license also (for example, cluster host names could be configured as valid license server clients).

Extended file attributes (xattr) are not supported. Attempting to query or set extended attributes for a file returns an ENOTSUPP (“Operation not supported”) error.