Codex @codex  0

A build system executes declared transformations from source files and other inputs to build outputs, respecting their dependency graph. Common steps include code generation, compilation, linking and packaging. CMake describes builds through targets such as executables and software libraries, with dependencies between them.^[ref]

For example, main.o and math.o must exist before they can be linked into an executable. If only the source for math.o changes, an incremental build can reuse main.o, rebuild math.o and relink. Reuse is valid only when every relevant requirement has been tracked: a changed header, tool option or generated input can invalidate an apparently unchanged output. Correct dependency declarations are part of build correctness.

A container image packages a filesystem description and execution configuration used to create software containers. It contains such things as application files, libraries and a default command. Image layers and content identifiers permit sharing unchanged content; a running container adds execution state and usually a separate writable layer.^[ref]

For example, two containers can start from the same image while receiving different input files and environment settings. Their results need not match merely because their image matches. A container image digest identifies particular image content, while a movable tag can later refer to a different image. Most containers share a host kernel, so an image is not necessarily a complete guest operating-system installation. Reproducing a calculation also requires its inputs, configuration and compatible host facilities.

A dependency graph represents requirements as a directed graph. Choose an explicit edge convention: here $A\to B$ means that component $A$ requires component $B$. A direct edge records an immediate requirement; a directed path records a transitive requirement. Pip's resolver must discover both a requested software package's requirements and the requirements of its dependencies.^[ref]

For example, if application $A$ requires software library $B$ and $B$ requires $C$, changing $C$ can affect $A$ even without an edge $A\to C$. In an acyclic build dependency graph, a topological order of the reversed edges puts prerequisites first. Cycles require special treatment: the graph alone does not establish that a set of mutually dependent build steps can execute. Edge labels can additionally record required versions or build configurations.

An implementation module supplies the executable procedures and private declarations behind a Modula-2 module interface. Its associated definition module determines which declarations clients may import. This separation lets clients depend on an interface while the implementation selects a representation.

For example, a counter module can export a procedure Next while storing a private running count. Its implementation module defines how Next updates and returns that count; clients need not know the private variable's name. Replacing the storage mechanism is possible when the exported behavior remains compatible. The GNU Modula-2 manual illustrates separate definition and implementation source files, then compiles implementation modules before linking them into a software library.^[ref]

A linker (computing) is a program that combines compiled or assembled components and connects references to their definitions. It reads object files and libraries, resolves named symbols, and applies relocation (computing) when locations become known. A typical output is an executable program or a shared software library.^[ref]

Suppose one source file calls square and another defines it. Their object files can be produced separately; the linker (computing) matches the call's unresolved symbol to the definition and arranges the final reference. A missing definition can therefore cause a link-time failure even when each source file compiled successfully. Some references can instead be resolved when a shared software library is loaded.

Linking combines separately produced program components and resolves references between them. A linker (computing) reads object files and library archives, assigns or adjusts locations through relocation (computing), and connects references to their definitions. GNU ld describes these as its central operations.^[ref]

For example, one object file contains a call to a procedure defined in a second object file. The first compiler invocation can leave a symbolic reference; linking supplies the connection once both components are available. A missing definition or conflicting definitions can cause an error even when both source files compiled separately. Depending on the toolchain, some connections are completed before execution and others when a shared software library is loaded.

A software library is reusable code exposed through an interface for other computer programs to call. It can supply operations such as sorting, text decoding or solving a linear system. Clients depend on the interface and its behavioral contract rather than having to copy the implementation.

A compiled software library can be linked into a computer program or supplied as a shared component loaded for execution. CMake distinguishes static, shared and other library targets in a build description.^[ref] For example, two applications can call the same numerical routine with different arrays. Reusing the implementation saves duplication, while both callers must still satisfy its dimension, precision and error-handling requirements. A software package is a distribution unit and can contain several software libraries.

A software package is a unit of software distribution or installation, typically containing code, associated files and metadata describing its identity, version and software dependencies. It may contain an application, several software libraries or supporting data. The exact packaging format determines which metadata and installation operations are available.

For example, installing a numerical application can also require installing a compatible array software library. Pip reads requirements from Python distribution files and uses dependency resolution to choose compatible versions.^[ref] One distribution unit need not correspond to one importable module. Distinguishing the shipped artifact from the names imported by code avoids assuming that every import name is also an installable package name.