NOTE:

Ryan McCoskrie (architect / developer of OfflineOS) does not yet fully understand Nix. Everything that follows is less-than-fully-informed ambitions.

Build is OfflineOS's equivalent of both Make and Nix.

Like Make the primary task of Build is invoking the compiler and linker on an as-needed basis for programs with many source files.

Like Nix on the other hand, Build is a declarative language that combines the tasks of package-management and configuration-management.

Unlike Nix, Build sources its packages from physical media rather than an online repository.

The essence of Build is the following ideas:

1. Each version of a package is installed into a different directory, which version is in use is a detail of the user's login session
2. A package consist of a function that adds/modifies files and environment variables to an installation of OfflineOS
3. These packages-as-functions can be passed arguments (install options) via a central config file
4. An installation of OfflineOS is a collection of specific package versions and whatever additional options have been injected via the central config file.

Therefore:

1. An installation is the sum of a chain of function calls.
2. Should an upgrade or reconfiguration fail, the system can be rolled-back to its previous state

Concepts in more detail

Combined build and package manager

The task of Build is to take a directory of files as input, apply commands to the files so that they match a formula and give resulting files as output in a different directory. A package is nothing more than an archive containing an input directory, a list of dependencies and a formula to apply to the input directory. In the case of an executable program, the input directory will at minimum contain a binary object file that will be dynamically linked with libraries provided by other packages before being placed in the output directory.

Combined package and configuration manager

Configuration of OfflineOS is to be performed through Build as a part of package installation (if needed individual packages will be re-installed on an as-needed basis). Users edit the formulae of the OfflineOS installations (AKA central configuration files) to override parameters of the packages listed for installation. Then during package installation these parameters are used to customise the contents of output directories. This might include text files, constant values baked into binary executables, names of sub-directories and much more.

Every version of every package has its own directory OR the importance of symbolic links

The output of installing every version of every package is stored in its own directory to prevent conflicts. The different packages then access their dependencies via symbolic links between their various respective directories. For example an application called "app", installed to the directory /packages/app-1.0 might have a dependency on version 1.1 of a library called "lib". Thus its installation directory would have a symbolic-link file called /packages/app-1.1/libs/lib.dll which would redirect to /packages/lib-1.1/lib.dll.