This module implements the build system that is used by pack_install/1 and pack_rebuild/1. The build system is a plugin based system where each plugin knows about a specific build toolchain. The plugins recognise whether they are applicable based on the existence of files that are unique to the toolchain. Currently it supports

• conan for the installation of dependencies
• cmake for configuration and building
• GNU tools including automake and autoconf for configuration and building

 build_steps(+Steps:list, SrcDir:atom, +Options) is det

Run the desired build steps. Normally, Steps is the list below, optionally prefixed with distclean or clean. [test] may be omited if --no-test is effective.

[[dependencies], [configure], build, [test], install]

Each step finds an applicable toolchain based on known unique files and calls the matching plugin to perform the step. A step may fail, which causes the system to try an alternative. A step that wants to abort the build process must throw an exception.

If a step fails, a warning message is printed. The message can be suppressed by enclosing the step in square brackets. Thus, in the above example of Steps, only failure by the build and install steps result in warning messages; failure of the other steps is silent.

The failure of a step can be made into an error by enclosing it in curly brackets, e.g. [[dependencies], [configure], {build}, [test], {install}] would throw an exception if either the build or install step failed.

Options are:

pack_version(N)

where N is 1 or 2 (default: 1). This determines the form of environment names that are set before the build tools are calledd. For version 1, names such as SWIPLVERSION or SWIHOME are used. For version 2, names such as SWIPL_VERSION or SWIPL_HOME_DIR are used.

@tbd If no tool is willing to execute some step, the step is skipped. This is ok for some steps such as dependencies or test. Possibly we should force the install step to succeed?

 ensure_build_dir(+Dir, +State0, -State) is det

Create the build directory. Dir is normally either '.' to build in the source directory or build to create a build subdir.

 prolog:build_environment(-Name, -Value) is nondet[multifile]

Hook to define the environment for building packs. This Multifile hook extends the process environment for building foreign extensions. A value provided by this hook overrules defaults provided by def_environment/3. In addition to changing the environment, this may be used to pass additional values to the environment, as in:

prolog:build_environment('USER', User) :-
    getenv('USER', User).

Arguments:

Name	- is an atom denoting a valid variable name
Value	- is either an atom or number representing the value of the variable.

 prolog_install_prefix(-Prefix) is semidet

Return the directory that can be passed into configure or cmake to install executables and other related resources in a similar location as SWI-Prolog itself. Tries these rules:

1. If the Prolog flag pack_prefix at a writable directory, use this.
2. If the current executable can be found on $PATH and the parent of the directory of the executable is writable, use this.
3. If the user has a writable ~/bin directory, use ~.

 run_process(+Executable, +Argv, +Options) is det

Run Executable. Defined options:

directory(+Dir)

Execute in the given directory

output(-Out)

Unify Out with a list of codes representing stdout of the command. Otherwise the output is handed to print_message/2 with level informational.

error(-Error)

As output(Out), but messages are printed at level error.

env(+Environment)

Environment passed to the new process.

If Executable is path(Program) and we have an environment we make sure to use the PATH from this environment for searching Program.

 path_sep(-Sep) is det

Path separator for the OS. ; for Windows, : for POSIX.

 has_program(+Spec) is semidet

 has_program(+Spec, -Path) is semidet

 has_program(+Spec, -Path, +Env:list) is semidet

True when the OS has the program Spec at the absolute file location Path. Normally called as e.g. has_program(path(cmake), CMakeExe). The second allows passing in an environment as Name=Value pairs. If this contains a value for PATH, this is used rather than the current path variable.