15.5.2 Packs with foreign code
Many packs include C or C++ resources. Such packs include the C or
C++ resources in a subdirectory of the pack. There are no restrictions
for naming this subdirectory or structuring the source files in this
directory. The build process must create native modules in the
directory lib/<arch>
, where <arch>
is the architecture as obtained by the Prolog flag arch.
The build process identifies control files that tell the package
manager which build tool to use. The package manager populates the
process environment with variables that provide details about the
running Prolog instance. This environment is saved in a file buildenv.sh
in the pack root or build directory. By
sourcing this file, the user may run the build tools by hand
for debugging purposes.
The build process consists of five steps that are described below
- dependencies
- This step currently only supports
conan
. It is executed if eitherconanfile.txt
orconanfile.py
is found in the root directory of the pack. - configure
- This preparation step is executed if one of
CMakeLists.txt
(cmake),configure
,configure.in
(autoconf),configure.ac
orMakefile.am
(automake) are found. The program to manage them is in parenthesis. - build
- Build the process. When configured using (cmake) this will use (cmake).
Otherwise either
Makefile
ormakefile
is expected and Unix make is used to build the process. - test
- Test the project. Either uses cmake or the GNU convention
make check
. - install
- Install the project. Either uses cmake or the GNU convention
make install
.
While running the above tools, the environment is populated. The
names of the variables provided depends on the pack_version(Version)
metadata. We give the names for version 2, with the names for
version 1 in parenthesis if this differs from the version 2
name.
PATH
- Contains the environment path with the directory holding the currently running SWI-Prolog instance prepended in front of it. As a result, swipl is always present and runs the same SWI-Prolog instance as the current Prolog process.
SWIPL
- Contains the absolute file name of the running executable.
SWIPL_PACK_VERSION
- Version of the pack system (1 or 2). If not present we must assume‘1’.
SWIPL_VERSION
(SWIPLVERSION
)- Contains the numeric SWI-Prolog version defined as Major × 10000 + Minor × 100 + Patch
SWIPL_HOME_DIR
(SWIHOME
)- Contains the directory holding the SWI-Prolog home.
SWIPL_ARCH
(SWIARCH
)- contains the machine architecture identifier.
SWIPL_MODULE_DIR
(PACKSODIR
)- constains the destination directory for shared objects/DLLs relative to
a Prolog pack, i.e.,
lib/$SWIARCH
. SWIPL_MODULE_LIB
(SWISOLIB
)- The SWI-Prolog library or an empty string when it is not required to link modules against this library (e.g., ELF systems)
SWIPL_LIB
(SWILIB
)- The SWI-Prolog library we need to link to for programs that
embed SWI-Prolog (normally
-lswipl
) SWIPL_INCLUDE_DIRS
- CMake style variable that contains the directory holding
SWI-Prolog.h
,SWI-Stream.h
andSWI-cpp2.h
. SWIPL_LIBRARIES_DIR
- CMake style variable that contains the directory holding
libswipl
SWIPL_CC
(CC
)- C compiler used to build SWI-Prolog.
SWIPL_LD
(LD
)- Linker used to link SWI-Prolog.
SWIPL_CFLAGS
(CFLAGS
)- C-Flags for building extensions. Always contains
-ISWIPL-INCLUDE-DIR
. SWIPL_MODULE_LDFLAGS
(LDSOFLAGS
)- Link flags for linking modules.
SWIPL_MODULE_EXT
(SOEXT
)- File name extension for modules (e.g.,
.so
or.dll
) SWIPL_PREFIX
(PREFIX
)- Install prefix for global binaries, libraries and include files.
15.5.2.1 Compiling a foreign extension using a simple Makefile
If the package requires some C code to be compiled that has no
dependencies and needs no configuration it is probably easiest to use a
simple Unix make file. We assume pack_version(2)
. Here is a
simple Makefile
. We assume the pack contains a file
c/environ.c
that contains the C source. Following the GNU
guidelines, the Makefile
must define the following targets:
- all (default)
- Build the foreign extension. In this very simple case we build the resulting module directly in the target directory.
- check
- Test the package. This is executed after the default build target.
- install
- Install the package. In this case this does nothing.
- clean
- Clean the package. This target disposes intermediate build products.
- distclean
- Restore the package to its fully clean state. This implies that all
built products and intermediate build products are removed. The
distclean
target is used by pack_rebuild/1.
MODULE= $(SWIPL_MODULE_DIR)/environ.$(SOEXT) CFLAGS= $(SWIPL_CFLAGS) all: $(MODULE) OBJ=c/environ.o $(MODULE): $(OBJ) mkdir -p $(SWIPL_MODULE_DIR) $(SWIPL_LD) $(SWIPL_MODULE_LDFLAGS) -o $@ $(OBJ) $(SWIPL_MODULE_LIB) check:: $(SWIPL) -g run_tests -t halt test/test_environ.pl install:: clean: rm -f $(OBJ) distclean: clean rm -f $(MODULE)
15.5.2.2 Publishing a pack
As described in section
15.4, a pack is distributed either as an archive file or as a GIT
repository. We strongly encourage using a GIT repository as that gives
good version and provenance support. Packs may be published by hand by
making the archive or git repository available from a globally
accessible place on the internet and installing the pack from this
location. This process is streamlined, notably for GIT packs using pack_publish/2
and the
app pack
. To publish a pack a local GIT repository
that has publicly accessible origin,
- Update
version(Version)
inpack.pl
- Commit all changes, make sure the the repository is clean.
- Run
swipl pack publish .
This will
- Verify the repository is clean and on the default branch.
- Tag the repository with V<version>. By default, the tag will be signed. Please setup signing for GIT or use the “--no-sign`` option.
- Push the repository and release tag.
- Figure out the download location, either from the
download(URL)
metadata or the GIT remote information. - Install the package and its dependencies in a temporary isolated pack environment.
- On success, register the pack with the server.
- Delete the isolated pack environment.
Similarly, a pack can be published from a public archive using the command below. When using an archive, never change the content of the archive but, instead, create a new archive with a new version.
swipl pack publish URL
15.5.2.3 Compiling a foreign extension using CMake
If the package is more complicated, a simple Makefile typically does not suffice. In this case we have two options. One is to use the GNU autoconf or automake. However, cmake is getting more popular and provides much better support for non-POSIX platforms, e.g., Windows. This section discusses building the same package as section 15.5.2.1 using cmake.
To use cmake, add the content below as the file
CMakeLists.txt
to the root directory of the pack.
SWI-Prolog ships with a cmake include file named
swipl.cmake
that deals with most of the configuration
issues. Comments in the file below explain the various steps of the
process.
cmake_minimum_required(VERSION 3.5) project(swipl-pack-environ) # Include swipl.cmake from the running SWI-Prolog's home list(INSERT CMAKE_MODULE_PATH 0 $ENV{SWIPL_HOME_DIR}/cmake) include(swipl) # Create the library as a CMake module add_library(environ MODULE c/environ.c) # Link the library to SWI-Prolog. This also removes the `lib` prefix # from the target on systems that define a common library file prefix target_link_swipl(environ) # Install the foreign taget. `${swipl_module_dir}` contains the # directory for installing modules for this architecture. install(TARGETS environ DESTINATION ${CMAKE_CURRENT_SOURCE_DIR}/${swipl_module_dir}) # Run tests. This is executed before the pack is installed. # swipl_test(name) runs Prolog with the command line below. # # swipl -p foreign=${CMAKE_CURRENT_SOURCE_DIR}/${swipl_module_dir} \ # -p library=${CMAKE_CURRENT_SOURCE_DIR}/prolog \ # --on-error=status \ # -g test_${name} \ # -t halt \ # ${CMAKE_CURRENT_SOURCE_DIR}/test/test_${name}.pl # # This implies that a test `name` must be defined in a file # `test/test_${name}.pl`, which exports a predicate `test_${name}`. The # test succeeds if this predicate succeeds and no error messages are # printed. enable_testing() swipl_add_test(environ)