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
dependent.
:- use_foreign_library(foreign(sqlite4pl)).
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:
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:
mingw
folder
on the same drive as where SWI-Prolog is installed.The build process consists of several steps, described below. Of these steps, only (3) is obligatory. In many cases, using configure can be omitted because these programs are called with a fair deal of information provided through the environment (see below).
configure.in
and no configure
, run
to create configure
configure
(distributed or created by the
previous step), run
Makefile
(distributed or created by the
previous steps), run
Note Ideally, if there is a suitable binary for the platform, pack_install/1 should not try to rebuild it. It is not clear how to verify this.
The configuration and installation steps are executed by pack_install/1 and provide the following environment variables:
-lswipl
on (X)COFF systems (Windows, MacOS) and empty on ELF systems (Linux).c_cc
Prolog
flag.c_cc
Prolog
flag.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 CFLAGS
environment variable.c_ldflags
, following by -shared
and the
value of the LDFLAGS
environment variable..
".The environment can be changed by providing clauses for the multifile predicate prolog_pack:environment/2. Answers of this predicate may provided additional environment variables. Answers for the above mentioned variables replace the above described value.
The infrastructure assumes using MinGW and MSYS for building foreign packages on Windows. If pack_install/1 detects a foreign pack on Windows, it performs the following steps to prepare MinGW: