|Did you know ...||Search Documentation:|
|Creating a pack that uses C or C++ code|
This page describes the basics for creating packages that contain C or C++ code, also known as foreign code.
Foreign code must be compiled into a SWI-Prolog extension, a loadable library. These things are supported by virtually any modern operating system under different names, e.g., DLL in Windows and shared object in Unix. A package may include such an extension. The package system can see this extension iff
arch. For example:
?- current_prolog_flag(arch, Arch). Arch = 'x86_64-linux'.
?- current_prolog_flag(shared_object_extension, Ext). Ext = so.
Provided that the above installation guidelines are followed, Prolog
code can include the extension using the directive use_foreign_library/1
as below. Note that
sqlite4pl is the example name of the extension.
The search path
foreign searches the lib/<arch> directories of
installed packages. The extension must be omitted because it is platform
Binary packages may include the lib/<arch> subdirectory in the package and suitable precompiled extensions for the target architectures. Note that how well this works depends on the binary compatibility of the platform as well as the mechanism used by the platform to resolve dependencies between Prolog and the extension. In particular:
and.so` shared objects. The latter are called modules by CMake. We use `.so` files for foreign extensions.
Alternatively, or in addition, the extensions may be provided as sources. The advantage thereof is that the above mentioned version dependencies do not apply. The disadvantage is that the user needs a suitable setup for running the C development tools and installed development libraries for dependencies. Here are some examples:
mingwfolder on the same drive as where SWI-Prolog is installed.
The build process is defined by the following steps:
The clean step is optional and used by pack_rebuild/1 in the mode
distclean. For each of the steps the system asks its build plugins to
identify known configuration files and perform the step. The planning
for a next step may depend on the output of the previous step. Below
is a list that describes the current strategy. New strategies may be
added by providing additional plugins for library(build/tools).
conanfile.pyis found in the toplevel directory, create a directory
conan install -b missing ..
If, as a result, a file
environment.sh.env is created in the
build directory, load the environment variables. This exploits
CMakeLists.txtis present create a subdirectory
cmake -DSWILP=.. -DCMAKE_INSTALL_PREFIX=... ..
makefileis found, run
CTestTestfile.cmakeis found in build, run
makefileis found, run `make check`
makefileis found, run `make install`
During all these steps the tools have access to details about Prolog through the environment variables described in the next section.
The configuration and installation steps are executed by pack_install/1 and provide the following environment variables:
-lswiplon (X)COFF systems (Windows, MacOS) and empty on ELF systems (Linux).
c_cflags, followed by -I<dir>, where <dir> is the directory holding
SWI-Prolog.h, followed by
-D__SWI_PROLOG__and the value of the
c_ldflags, following by
-sharedand the value of the
The environment can be changed by providing clauses for the multifile predicate environment/2. Answers of this predicate may provided additional environment variables. Answers for the above mentioned variables replace the above described value.