Documentation - Featureless Make - Specification - Settings
Author: Kevin Day
Description: Featureless Make program settings specification.
Keywords: Kevin Day, Kevux, FLL, Featureless, Linux, Library, Featureless Make, Open-Source, Specification

# Featureless Make Settings Specification

The build settings settings file follows the `FSS-0001 (Extended)` format.

Each Object represents a settings property name.

There is only a distinct set of setting property names (see below).

Each Content represents the values associated with that property.

Additional restrictions are applied to each Content depending on each specific Object name (see below).

Object Names and their respective Content purpose/restrictions:

- `build_compiler`: Must only be a valid filename.
- `build_indexer`: Must only be a valid filename.
- `build_indexer_arguments`: Zero or more arguments supported by the indexer specified in `build_indexer`.
- `build_language`: Must only be one of: `bash`, `c`, or `c++`.
- `build_libraries`: Must only contain any number of valid library include arguments that are valid for the compiler defined in "build_compiler" Object.
- `build_libraries_shared`: Must only contain any number of valid library include arguments that are valid for the compiler defined in "build_compiler" Object.
- `build_libraries_static`: Must only contain any number of valid library include arguments that are valid for the compiler defined in "build_compiler" Object.
- `build_name`: Must only contain characters allowed in a filename.
- `build_objects_library`: Must only contain any number of valid object file names relative to the appropriate `path_object_*` path.
- `build_objects_library_shared`: Must only contain any number of valid object file names relative to the `path_object_shared` path.
- `build_objects_library_static`: Must only contain any number of valid object file names relative to the `path_object_static` path.
- `build_objects_program`: Must only contain any number of valid object file names relative to the appropriate `path_object_*` path.
- `build_objects_program_shared`: Must only contain any number of valid object file names relative to the `path_object_shared` path.
- `build_objects_program_static`: Must only contain any number of valid object file names relative to the `path_object_static` path.
- `build_script`: Must only one of: `yes` or `no`.
- `build_shared`: Must only one of: `yes` or `no`.
- `build_sources_headers`: Must only contain any number of valid filenames.
- `build_sources_headers_shared`: Must only contain any number of valid filenames.
- `build_sources_headers_static`: Must only contain any number of valid filenames.
- `build_sources_library`: Must only contain any number of valid filenames.
- `build_sources_library_shared`: Must only contain any number of valid filenames.
- `build_sources_library_static`: Must only contain any number of valid filenames.
- `build_sources_object`: Must only contain any number of valid filenames.
- `build_sources_object_shared`: Must only contain any number of valid filenames.
- `build_sources_object_static`: Must only contain any number of valid filenames.
- `build_sources_program`: Must only contain any number of valid filenames.
- `build_sources_program_shared`: Must only contain any number of valid filenames.
- `build_sources_program_static`: Must only contain any number of valid filenames.
- `build_sources_script`: Must only contain any number of valid filenames.
- `build_sources_setting`: Must only contain any number of valid filenames.
- `build_static`: Must only one of: `yes` or `no`.
- `defines`: Must only contain any number of valid macro names supported by the compiler specified in `build_compiler`.
- `defines_library`: Must only contain any number of valid macro names supported by the compiler specified in `build_compiler`.
- `defines_library_shared`: Must only contain any number of valid macro names supported by the compiler specified in `build_compiler`.
- `defines_library_static`: Must only contain any number of valid macro names supported by the compiler specified in `build_compiler`.
- `defines_object`: Must only contain any number of valid macro names supported by the compiler specified in `build_compiler`.
- `defines_object_shared`: Must only contain any number of valid macro names supported by the compiler specified in `build_compiler`.
- `defines_object_static`: Must only contain any number of valid macro names supported by the compiler specified in `build_compiler`.
- `defines_program`: Must only contain any number of valid macro names supported by the compiler specified in `build_compiler`.
- `defines_program_shared`: Must only contain any number of valid macro names supported by the compiler specified in `build_compiler`.
- `defines_program_static`: Must only contain any number of valid macro names supported by the compiler specified in `build_compiler`.
- `defines_shared`: Must only contain any number of valid macro names supported by the compiler specified in `build_compiler`.
- `defines_static`: Must only contain any number of valid macro names supported by the compiler specified in `build_compiler`.
- `environment`: Environment variable names, case-sensitive, usually uppercase. May only contain characters allowed in an environment variable.
- `flags`: Must only contain any number of parameters supported by the compiler specified in `build_compiler`.
- `flags_library`: Must only contain any number of parameters supported by the compiler specified in `build_compiler`.
- `flags_library_shared`: Must only contain any number of parameters supported by the compiler specified in `build_compiler`.
- `flags_library_static`: Must only contain any number of parameters supported by the compiler specified in `build_compiler`.
- `flags_object`: Must only contain any number of parameters supported by the compiler specified in `build_compiler`.
- `flags_object_shared`: Must only contain any number of parameters supported by the compiler specified in `build_compiler`.
- `flags_object_static`: Must only contain any number of parameters supported by the compiler specified in `build_compiler`.
- `flags_program`: Must only contain any number of parameters supported by the compiler specified in `build_compiler`.
- `flags_program_shared`: Must only contain any number of parameters supported by the compiler specified in `build_compiler`.
- `flags_program_static`: Must only contain any number of parameters supported by the compiler specified in `build_compiler`.
- `flags_shared`: Must only contain any number of parameters supported by the compiler specified in `build_compiler`.
- `flags_static`: Must only contain any number of parameters supported by the compiler specified in `build_compiler`.
- `has_path_standard`: Must only one of: `yes` or `no`.
- `modes`: Any valid word character, `-`, or `+`.
- `modes_default`: May only be a single complete Content word defined in `modes` Object.
- `path_headers`: Must be a single valid path.
- `path_language`: Must be a single valid path.
- `path_library_script`: Must be a single valid path.
- `path_library_shared`: Must be a single valid path.
- `path_library_static`: Must be a single valid path.
- `path_object_script`: Must be a single valid path.
- `path_object_shared`: Must be a single valid path.
- `path_object_static`: Must be a single valid path.
- `path_program_script`: Must be a single valid path.
- `path_program_shared`: Must be a single valid path.
- `path_program_static`: Must be a single valid path.
- `path_sources`: Must only be a valid directory path or not specified.
- `path_sources_headers`: Must only be a valid directory path or not specified.
- `path_sources_library`: Must only be a valid directory path or not specified.
- `path_sources_object`: Must only be a valid directory path or not specified.
- `path_sources_program`: Must only be a valid directory path or not specified.
- `path_sources_script`: Must only be a valid directory path or not specified.
- `preserve_path_headers`: Must only be one of `yes` or `no`.
- `process_post`: Must contain only a single valid filename.
- `process_pre`: Must contain only a single valid filename.
- `search_exclusive`: Must only one of: `yes` or `no`.
- `search_shared`: Must only one of: `yes` or `no`.
- `search_static`: Must only one of: `yes` or `no`.
- `stage`: Only zero or one Content, which represents the build stage name (case-sensitive) (no slashes allowed).
- `version_file`: Must only be one of: `major`, `minor`, `micro`, or `nano`.
- `version_major`: Must only be a single value containing valid filename characters.
- `version_major_prefix`: Must be zero or more valid filename characters.
- `version_micro`: Must only be a single value containing valid filename characters.
- `version_micro_prefix`: Must be zero or more valid filename characters.
- `version_minor`: Must only be a single value containing valid filename characters.
- `version_minor_prefix`: Must be zero or more valid filename characters.
- `version_nano`: Must only be a single value containing valid filename characters.
- `version_nano_prefix`: Must be zero or more valid filename characters.
- `version_target`: Must only be one of: `major`, `minor`, `micro`, or `nano`.

All Object names support having a `-` and a `mode` name, such as `build_libraries-individual` for a mode called `individual`, except for the `modes` and the `modes_default` Object names.

## Settings Documentation

This describes intent and purposes of the build settings file settings.

The settings file is designed for very simple compilations that represent a single named program and/or a single named library.

For specific details on the allowed formatting, see the settings.txt under the specifications folder.

- `build_compiler`:

  This represents the name of the compiler program to use, such as `gcc`.

  This defaults to `gcc` (the GNU C Compiler).

  The programs `gcc` and `clang` are known to work.

  Many of the parameters in the settings file can be changed if using a non-GCC, but there may be certain hard-coded functionality that may need to be changed.

- `build_indexer`:

  This represents the name of the indexer program to use, such as `ar`.

  An indexer is often called a linker.

  This defaults to `ar` (the GNU `ar` program).

  Similar to `build_compiler`, any linker that supports the `ar` program parameters is effectively supported.

- `build_indexer_arguments`:

  This represents arguments needed to build an archive file from object files, such as `rcs`.

  These arguments are placed immediately before the object files passed to the `indexer` program.

- `build_language`:

  The programming language to build with.

  The languages `c` and `c++` are supported (with `bash` as a consideration for support).

  The `bash` language is not currently implemented and needs some consideration because there is nothing to compile.

  The `bash` language will likely build a set of individual scripts, and perhaps script dependencies, into a single Bash script.

- `build_libraries`:

  A collection of libraries to be linked against.

  This should include the compiler specific parameter parts, such as the `-l` prefix in `-lc`.

  The order of these may matter if the compiler (such as GCC or a linker via GCC) is order sensitive.

- `build_libraries_shared`:

  A collection of libraries to be linked against.

  This should include the compiler specific parameter parts, such as the `-l` prefix in `-lc`.

  The order of these may matter if the compiler (such as GCC or a linker via GCC) is order sensitive.

  These are applied to only shared builds.

- `build_libraries_static`:

  A collection of libraries to be linked against.

  This should include the compiler specific parameter parts, such as the `-l` prefix in `-lc`.

  The order of these may matter if the compiler (such as GCC or a linker via GCC) is order sensitive.

  These are applied to only static builds.

- `build_objects_library`:

  A collection of object files to be compile with when building libraries.

  These are intended to represent already compiled object files.

  These paths are relative to the `path_object_script`, `path_object_shared`, or `path_object_static`.

  The order of these may matter if the compiler (such as GCC or a linker via GCC) is order sensitive.

- `build_objects_library_shared`:

  A collection of object files to be compile with when building shared libraries.

  These are intended to represent already compiled object files.

  These paths are relative to the `path_object_shared`.

  The order of these may matter if the compiler (such as GCC or a linker via GCC) is order sensitive.

  These are applied to only shared builds.

- `build_objects_library_static`:

  A collection of object files to be compile with when building static libraries.

  These are intended to represent already compiled object files.

  These paths are relative to the `path_object_static`.

  The order of these may matter if the compiler (such as GCC or a linker via GCC) is order sensitive.

  These are applied to only static builds.

- `build_objects_program`:

  A collection of object files to be compile with when building programs.

  These are intended to represent already compiled object files.

  These paths are relative to the `path_object_script`, `path_object_shared`, or `path_object_static`.

  The order of these may matter if the compiler (such as GCC or a linker via GCC) is order sensitive.

- `build_objects_program_shared`:

  A collection of object files to be compile with when building shared programs.

  These are intended to represent already compiled object files.

  These paths are relative to the `path_object_shared`.

  The order of these may matter if the compiler (such as GCC or a linker via GCC) is order sensitive.

  These are applied to only shared builds.

- `build_objects_program_static`:

  A collection of object files to be compile with when building static programs.

  These are intended to represent already compiled object files.

  These paths are relative to the `path_object_static`.

  The order of these may matter if the compiler (such as GCC or a linker via GCC) is order sensitive.

  These are applied to only static builds.

- `build_name`:

  The name of the build, which often represent the project name.

  If program sources are specified, then this will be used as the program name.

  If library sources are specified, then this will be used in the library name, such as `libX.so` where `X` would be the `build_name` value.

- `build_script`:

  When `yes`, the build process will build any scripts, such as a Bash script.

  This is currently not implemented.

- `build_shared`:

  When `yes`, the build process will compile any source code for any supported language that supports shared library linking.

- `build_sources_headers`:

  A collection of header files.

  May include a relative sub-path to each individual header (such as: `level_0/a.h level_0/b.h level_1/c.h`).

  The order of these may matter if the compiler (such as GCC or a linker via GCC) is order sensitive.

- `build_sources_headers_shared`:

  A collection of header files.

  May include a relative sub-path to each individual header (such as: `level_0/a.h level_0/b.h level_1/c.h`).

  The order of these may matter if the compiler (such as GCC or a linker via GCC) is order sensitive.

  Be careful not to have any conflicting names between this and build_sources_headers_static in case of when static and shared builds are both enabled.

  These are applied to only shared builds.

- `build_sources_headers_static`:

  A collection of header files.

  May include a relative sub-path to each individual header (such as: `level_0/a.h level_0/b.h level_1/c.h`).

  The order of these may matter if the compiler (such as GCC or a linker via GCC) is order sensitive.

  These files are used when compiling the library.

  Be careful not to have any conflicting names between this and build_sources_headers_shared in case of when static and shared builds are both enabled.

  These are applied to only static builds.

- `build_sources_library`:

  A collection of library related source files.

  May include a relative sub-path to each individual source file (such as: `level_0/a.c level_0/b.c level_1/c.c`).

  The order of these may matter if the compiler (such as GCC or a linker via GCC) is order sensitive.

- `build_sources_library_shared`:

  A collection of library related source files.

  May include a relative sub-path to each individual source file (such as: `level_0/a.c level_0/b.c level_1/c.c`).

  The order of these may matter if the compiler (such as GCC or a linker via GCC) is order sensitive.

  These are applied to only shared builds.

- `build_sources_library_static`:

  A collection of library related source files.

  May include a relative sub-path to each individual source file (such as: `level_0/a.c level_0/b.c level_1/c.c`).

  The order of these may matter if the compiler (such as GCC or a linker via GCC) is order sensitive.

  These are applied to only static builds.

- `build_sources_object`:

  A single source file used for generating an object file.

  The source file is located within the path designated by `path_sources_object`.

  The built object does not get linked and therefore no linker arguments apply.

  The built object file is named using the `build_name` with the `.o` extension.

  May include a relative sub-path to each individual source file (such as: `level_0/a.c`).

- `build_sources_object_shared`:

  A single source file used for generating an object file.

  The source file is located within the path designated by `path_sources_object`.

  The built object does not get linked and therefore no linker arguments apply.

  The built object file is named using the `build_name` with the `.o` extension.

  May include a relative sub-path to each individual source file (such as: `level_0/a.c`).

  These are applied to only shared builds.

- `build_sources_object_static`:

  A single source file used for generating an object file.

  The source file is located within the path designated by `path_sources_object`.

  The built object does not get linked and therefore no linker arguments apply.

  The built object file is named using the `build_name` with the `.o` extension.

  May include a relative sub-path to each individual source file (such as: `level_0/a.c`).

  These are applied to only static builds.

- `build_sources_program`:

  A collection of program related source files.

  May include a relative sub-path to each individual source file (such as: `level_0/a.c level_0/b.c level_1/c.c`).

  The order of these may matter if the compiler (such as GCC or a linker via GCC) is order sensitive.

  These files are used when compiling the program.

- `build_sources_program_shared`:

  A collection of program related source files.

  May include a relative sub-path to each individual source file (such as: `level_0/a.c level_0/b.c level_1/c.c`).

  The order of these may matter if the compiler (such as GCC or a linker via GCC) is order sensitive.

  These files are used when compiling the program for shared builds.

- `build_sources_program_static`:

  A collection of program related source files.

  May include a relative sub-path to each individual source file (such as: `level_0/a.c level_0/b.c level_1/c.c`).

  The order of these may matter if the compiler (such as GCC or a linker via GCC) is order sensitive.

  These files are used when compiling the program for static builds.

- `build_sources_script`:

  A collection of script files.

  These are settings files used by the project and are simply copied over to the build directory.

  Unless a pre-process script (or in theory post-process script) is configured to alter these, they are not modified.

  Unlike the `compile_language` setting `bash`, this is not for built Bash script, but is instead for any valid scripting language (including Bash).

  These could be in any language.

- `build_sources_setting`:

  A collection of settings files.

  These are settings files used by the project and are simply copied over to the build directory.

  Unless a pre-process script (or in theory post-process script) is configured to alter these, they are not modified.

- `build_static`:

  When `yes`, the build process will compile any source code for any supported language that supports static library linking.

- `defines`:

  A collection of macro names.

  This includes the any compiler specific parameters required by the `build_compiler`, such as the `-D` used by `gcc` and `clang`.

  These will be appended to the compiler for compiled languages such as `C` and `C++`.

  These are applied to both shared and static builds.

- `defines_library`:

  A collection of macro names.

  This includes the any compiler specific parameters required by the `build_compiler`, such as the `-D` used by `gcc` and `clang`.

  These will be appended to the compiler for compiled languages such as `C` and `C++`.

  These are applied to only library builds.

- `defines_library_shared`:

  A collection of macro names.

  This includes the any compiler specific parameters required by the `build_compiler`, such as the `-D` used by `gcc` and `clang`.

  These will be appended to the compiler for compiled languages such as `C` and `C++`.

  These are applied to only shared library builds.

- `defines_library_static`:

  A collection of macro names.

  This includes the any compiler specific parameters required by the `build_compiler`, such as the `-D` used by `gcc` and `clang`.

  These will be appended to the compiler for compiled languages such as `C` and `C++`.

  These are applied to only static library builds.

- `defines_object`:

  A collection of macro names.

  This includes the any compiler specific parameters required by the `build_compiler`, such as the `-D` used by `gcc` and `clang`.

  These will be appended to the compiler for compiled languages such as `C` and `C++`.

  These are applied to only object builds.

- `defines_object_shared`:

  A collection of macro names.

  This includes the any compiler specific parameters required by the `build_compiler`, such as the `-D` used by `gcc` and `clang`.

  These will be appended to the compiler for compiled languages such as `C` and `C++`.

  These are applied to only shared object builds.

- `defines_object_static`:

  A collection of macro names.

  This includes the any compiler specific parameters required by the `build_compiler`, such as the `-D` used by `gcc` and `clang`.

  These will be appended to the compiler for compiled languages such as `C` and `C++`.

  These are applied to only static object builds.

- `defines_program`:

  A collection of macro names.

  This includes the any compiler specific parameters required by the `build_compiler`, such as the `-D` used by `gcc` and `clang`.

  These will be appended to the compiler for compiled languages such as `C` and `C++`.

  These are applied to only program builds.

- `defines_program_shared`:

  A collection of macro names.

  This includes the any compiler specific parameters required by the `build_compiler`, such as the `-D` used by `gcc` and `clang`.

  These will be appended to the compiler for compiled languages such as `C` and `C++`.

  These are applied to only shared program builds.

- `defines_program_static`:

  A collection of macro names.

  This includes the any compiler specific parameters required by the `build_compiler`, such as the `-D` used by `gcc` and `clang`.

  These will be appended to the compiler for compiled languages such as `C` and `C++`.

  These are applied to only shared program builds.

- `defines_shared`:

  A collection of macro names.

  This includes the any compiler specific parameters required by the `build_compiler`, such as the `-D` used by `gcc` and `clang`.

  These will be appended to the compiler for compiled languages such as `C` and `C++`.

  These are applied to only shared builds.

- `defines_static`:

  A collection of macro names.

  This includes the any compiler specific parameters required by the `build_compiler`, such as the `-D` used by `gcc` and `clang`.

  These will be appended to the compiler for compiled languages such as `C` and `C++`.

  These are applied to only static builds.

- `environment`:

  A collection of environment names to pass from the callers environment into the executed programs environment.

  When provided, all environment variables are removed when calling user-space programs, such as `gcc`.

  To remove all environment variables define this with no Content.

  When not provided, all environment variables are loaded.

- `flags`:

  A collection of any flag supported by the `build_compiler`, such as `gcc`.

  This includes the any compiler specific parameters to defined this, such as the `-f` used by `gcc` and `clang`.

  These are applied to both shared and static builds.

- `flags_library`:

  A collection of any flag supported by the `build_compiler`, such as `gcc`.

  This includes the any compiler specific parameters to defined this, such as the `-f` used by `gcc` and `clang`.

  These are applied when building a library.

- `flags_library_shared`:

  A collection of any flag supported by the `build_compiler`, such as `gcc`.

  This includes the any compiler specific parameters to defined this, such as the `-f` used by `gcc` and `clang`.

  These are applied to only library shared builds.

- `flags_library_static`:

  A collection of any flag supported by the `build_compiler`, such as `gcc`.

  This includes the any compiler specific parameters to defined this, such as the `-f` used by `gcc` and `clang`.

  These are applied to only library static builds.

- `flags_object`:

  A collection of any flag supported by the `build_compiler`, such as `gcc`.

  This includes the any compiler specific parameters to defined this, such as the `-f` used by `gcc` and `clang`.

  These are applied when building an object.

- `flags_object_shared`:

  A collection of any flag supported by the `build_compiler`, such as `gcc`.

  This includes the any compiler specific parameters to defined this, such as the `-f` used by `gcc` and `clang`.

  These are applied to only object shared builds.

- `flags_object_static`:

  A collection of any flag supported by the `build_compiler`, such as `gcc`.

  This includes the any compiler specific parameters to defined this, such as the `-f` used by `gcc` and `clang`.

  These are applied to only object static builds.

- `flags_program`:

  A collection of any flag supported by the `build_compiler`, such as `gcc`.

  This includes the any compiler specific parameters to defined this, such as the `-f` used by `gcc` and `clang`.

  These are applied when building a program.

- `flags_program_shared`:

  A collection of any flag supported by the `build_compiler`, such as `gcc`.

  This includes the any compiler specific parameters to defined this, such as the `-f` used by `gcc` and `clang`.

  These are applied to only program shared builds.

- `flags_program_static`:

  A collection of any flag supported by the `build_compiler`, such as `gcc`.

  This includes the any compiler specific parameters to defined this, such as the `-f` used by `gcc` and `clang`.

  These are applied to only program static builds.

- `flags_shared`:

  A collection of any flag supported by the `build_compiler`, such as `gcc`.

  This includes the any compiler specific parameters to defined this, such as the `-f` used by `gcc` and `clang`.

  These are applied to only shared builds.

- `flags_static`:

  A collection of any flag supported by the `build_compiler`, such as `gcc`.

  This includes the any compiler specific parameters to defined this, such as the `-f` used by `gcc` and `clang`.

  These are applied to only static builds.

- `has_path_standard`:

  When `yes`, the sources path will be built using the sources path with the language, such as `sources/c/`.

  When `no`, the default sources path structure is not used and instead `path_sources` is used.

  When the parameter `-S/--sources` is specified, such as `-S xxx`, then when this is set to `yes` is used then the path would be `xxx/c/` and when this is set to `no` then the path would be `xxx/`.

  This defaults to `yes`.

- `modes`:

  A collection of available build modes.

  Build modes provide custom variants of the build process where certain settings are appended onto others.

  See the settings.txt specification for a list of which setting names this applies to.

- `modes_default`:

  The name of the default mode to use when no mode is specified.

  This must be one of the modes specified in the `modes` setting.

- `path_headers`:

  A sub-path in which headers are to be installed under.

  For example, the FLL project might use the `level_0`, `level_1`, etc.. headers without requiring that structure within the source.

  A resulting build destination for a `path_headers` of `level_0` would be something like `build/includes/level_0/`.

  If `path_headers` is `level_0`, `preserve_path_headers` is `yes`, and `build_sources_headers` has `xxx/a.h yyy/zzz/b.h`, then the headers would be at: `build/includes/level_0/xxx/a.h build/includes/level_0/yyy/zzz/b.h`

- `path_language`:

  A sub-path in which to find the source files for the currently defined language.

  If the `build_language` is changed, it is recommended to change this as well to match.

- `path_library_script`:

  A sub-path representing the destination where the built library script files are placed.

  This defaults to `script`.

  This is currently not implemented.

- `path_library_shared`:

  A sub-path representing the destination where the built shared library files are placed.

  This defaults to `shared`.

- `path_library_static`:

  A sub-path representing the destination where the built shared library files are placed.

  This defaults to `static`.

- `path_object_script`:

  A sub-path representing the destination where the built object script files are placed.

  This defaults to `script`.

  This is currently not implemented.

- `path_object_shared`:

  A sub-path representing the destination where the built object library files are placed.

  This defaults to `shared`.

- `path_object_static`:

  A sub-path representing the destination where the built object library files are placed.

  This defaults to `static`.

- `path_program_script`:

  A sub-path representing the destination where the built program script files are placed.

  This defaults to `script`.

  This is currently not implemented.

- `path_program_shared`:

  A sub-path representing the destination where the built shared program files are placed.

  This defaults to `shared`.

- `path_program_static`:

  A sub-path representing the destination where built shared program files are placed.

  This defaults to `static`.

- `path_sources`:

  A sub-path representing where the source files are found.

  This defaults to `sources`.

- `path_sources_object`:

  A sub-path representing where the object source files are found.

  This is used by `build_sources_object`.

  This defaults to `sources`.

- `preserve_path_headers`:

  When this is `yes`, then the relative directory structure in the source (as defined in `build_sources_headers`) is preserved.

  If the `build_sources_headers` has the header files `xxx/a.h yyy/zzz/b.h` and this is `yes`, then the directories `xxx/` and `yyy/zzz/` are created and the files are stored within them.

  If the `build_sources_headers` has the header files `xxx/a.h yyy/zzz/b.h` and this is `no`, then the directories `xxx/` and `yyy/zzz/` are stripped before installing.

  When this is `no` and the `build_sources_headers` has header files `xxx/a.h yyy/a.h`, then one of the `a.h` files will be overwritten, depending on order they were supplied.

- `process_post`:

  The filename (relative to the `data/build/` directory) of a script to execute after the `build` operation successfully completes.

  A small subset of parameters from the main execution are passed to this script during execution as parameters (using short parameter codes):

  - Color context parameters, such as: `+l`, `+n`, and `+d`.
  - Operation mode, such as: `build`, `clean`, `make`, or `skeleton`.
  - Verbosity parameters, such as: `+q`, `+D`, or `+V`.
  - Define parameters, such as `-d X` or `-d Y`, whereas `X` or `Y` are any valid argument associated with `-d`.
  - Process parameter, such as `-p X`, whereas `X` is any valid argument associated with `-p`.
  - Settings parameter, such as `-s X', whereas code:`X" is any valid argument associated with `-s`.
  - Build Path parameter, such as `-b X', whereas code:`X" is any valid argument associated with `-b`.
  - Data Path parameter, such as `-D X', whereas code:`X" is any valid argument associated with `-D`.
  - Sources Path parameter, such as `-S X', whereas code:`X" is any valid argument associated with `-S`.
  - Work Path parameter, such as `-w X', whereas code:`X" is any valid argument associated with `-w`.
- `process_pre`:

  The filename (relative to the `data/build/` directory) of a script to execute before the `build` operation is executed.

  A small subset of parameters from the main execution are passed to this script during execution as parameters (using short parameter codes):

  - Color context parameters, such as: `+l`, `+n`, and `+d`.
  - Operation mode, such as: `build`, `clean`, `make`, or `skeleton`.
  - Verbosity parameters, such as: `+q`, `+D`, or `+V`.
  - Define parameters, such as `-d X` or `-d Y`, whereas `X` or `Y` are any valid argument associated with `-d`.
  - Process parameter, such as `-p X`, whereas `X` is any valid argument associated with `-p`.
  - Settings parameter, such as `-s X', whereas code:`X" is any valid argument associated with `-s`.
  - Build Path parameter, such as `-b X', whereas code:`X" is any valid argument associated with `-b`.
  - Data Path parameter, such as `-D X', whereas code:`X" is any valid argument associated with `-D`.
  - Sources Path parameter, such as `-S X', whereas code:`X" is any valid argument associated with `-S`.
  - Work Path parameter, such as `-w X', whereas code:`X" is any valid argument associated with `-w`.
- `search_exclusive`:

  When `yes`, the search path during compile for shared libraries will only include shared library paths.

  When `no`, the search path during compile time for shared libraries will include shared library paths followed by static library paths.

  Setting this to `yes` helps prevent static libraries from ending up in shared libraries (very useful when bootstrapping a system).

  Setting this to `no` allows for including static libraries if no shared libraries are found but static are.

  This does not alter search paths introduced automatically by the `build_compiler` or `build_indexer`, so it is still possible for static libraries to end up even when this is set to `yes`.

- `search_shared`:

  When `yes`, shared library paths are searched during compile.

  Both this and `search_static` cannot be `no` at the same time.

  This defaults to `yes`.

- `search_shared`:

  When `yes`, static library paths are searched during compile.

  Both this and search_shared cannot be `no` at the same time.

- `stage`:

  This defines a name that is added to the build stage files to help uniquely identify build stages associated with this file.

  This name must only have valid characters for a particular file system.

  The variables allowed are different from file system to file system and so special characters should generally be avoided.

  To help prevent problems with paths, slashes (forward slash and backward slash) are not allowed in the stage name.

- `version_file`:

  Designates which version should be used when building the symbolic links.

  Any version prefixes are used as defined.

  A Symbolic link is created against this created file such that `libX.so` is a link to `libX.so.A`.

  For all files other than when file is `major`, another symbolic link is created against this such that `libX.so.A` is a link to `libX.so.A.X` such that X is the respective `B`, `B.C', or code:`B.C.D" as described below.

  The default file is `major`.

  When `major` is used, the file created is `libX.so.A`, whereas `X` is the `build_name` and `A` is the major version.

  When `minor` is used, the file created is `libX.so.A.B`, whereas `X` is the `build_name` and `A.B` is the major and minor versions, respectively.

  When `micro` is used, the file created is `libX.so.A.B.C`, whereas `X` is the `build_name` and `A.B.C` is the major, minor, and micro versions, respectively.

  When `nano` is used, the file created is `libX.so.A.B.C.D`, whereas `X` is the `build_name` and `A.B.C.D` is the major, minor, micro, and nano versions, respectively.

- `version_major`:

  The major version number (or in theory any characters allowed in a filename).

  This should generally be a positive number or 0.

  Anything else is currently untested but allowed.

  With a structure of `A.B.C`, the major version would be the `A`.

- `version_major_prefix`:

  The version major prefix is the character used to designate the start of the major version.

  This can zero or more characters.

  With a structure of `A.B.C`, the major version prefix would be before the `A`.

  This is only added if `version_major` is not empty.

  This defaults to the ASCII period character `.`.

- `version_minor`:

  The minor version number (or in theory any characters allowed in a filename).

  This should generally be a positive number or 0.

  Anything else is currently untested but allowed.

  With a structure of `A.B.C`, the minor version would be the `B`.

- `version_minor_prefix`:

  The version minor prefix is the character used to separate the major from the minor.

  This can zero or more characters.

  With a structure of `A.B.C`, the minor version prefix would be the `.` before the `B`.

  This is only added if `version_minor` is not empty.

  This defaults to the ASCII period character `.`.

- `version_micro`:

  The micro version number (or in theory any characters allowed in a filename).

  This should generally be a positive number or 0.

  Anything else is currently untested but allowed.

  With a structure of `A.B.C`, the micro version would be the `C`.

- `version_micro_prefix`:

  The version micro prefix is the character used to separate the minor from the micro.

  This can zero or more characters.

  With a structure of `A.B.C`, the micro version prefix would be the `.` before the `C`.

  This is only added if `version_micro` is not empty.

  This defaults to the ASCII period character `.`.

- `version_nano`:

  The nano version number (or in theory any characters allowed in a filename).

  This should generally be a positive number or 0.

  Anything else is currently untested but allowed.

  With a structure of `A.B.C.D`, the micro version prefix would be the `.` before the `D`.

- `version_nano_prefix`:

  The version nano prefix is the character used to separate the micro from the nano.

  This can zero or more characters.

  With a structure of `A.B.C.D`, the minor version would be the `.` before the `D`.

  This is only added if `version_nano` is not empty.

  This defaults to the ASCII period character `.`.

- `version_target`:

  Designates which version should be used when linking the shared library.

  Any version prefixes are used as defined.

  The default target is `micro`.

  When `major` is used, a shared library is generated with `-Wl,-soname,libX.so.A`, whereas `X` is the `build_name` and `A` is the major version.

  When `minor` is used, a shared library is generated with `-Wl,-soname,libX.so.A.B`, whereas `X` is the `build_name` and `A.B` is the major and minor versions, respectively.

  When `micro` is used, a shared library is generated with `-Wl,-soname,libX.so.A.B.C`, whereas `X` is the `build_name` and `A.B.C` is the major, minor, and micro versions, respectively.

  When `nano` is used, a shared library is generated with `-Wl,-soname,libX.so.A.B.C.D`, whereas `X` is the `build_name` and `A.B.C.D` is the major, minor, micro, and nano versions, respectively.