I’ve pushed a lot of patches to facilitate compiling the entire library to .qlf (Quick Load Format` files. This was proposed by @maren. Thanks! This has several advantages
.qlf files load about 20 times faster. That notably affects applications that load a lot of libraries. For example, loading s(CASP) from source on my dev machine drops from 0.45 sec to 0.17 sec. Loading big libraries such as clpfd and chr. E.g., use_module(library(clpfd)) drops from 0.11 to 0.006 sec.
.qlf files are about 50% smaller. SWI-Prolog now also supports installing only .qlf files. That is good news for e.g., the WASM version. Of course, the price is that source-level tracing through the libraries no longer works and it is harder to inspect the implementation.
These new features are still experimental. It they interest you, pick the latest git version and run cmake with these additional flags
-DINSTALL_QLF=ON Build and install the library .qlf files.
-DINSTALL_PROLOG_SRC=OFF Install only the .qlf files
If you install both (probably recommended for most purposes), you can run SWI-Prolog like below to make it load the source rather than the .qlf files.
swipl -Dsource ...
Alternatively, you can use ?- set_prolog_flag(source, true). to achieve the same result for each file loaded after changing this flag. Loading the source may be useful to verify that unexpected behaviour is due to issues with the .qlf files. In addition if can be used to improve debugging libraries because the precompiled libraries are compiled with optimization enabled and debug/3 and assertion/1 statements removed.
Once this proofs stable, INSTALL_QLF will be changed to default to ON.
I don’t know if this is related to the .qlf files, but I noticed that the install_manifest.txt is now empty or missing; when I build with CMAKE_INSTALL_MODE=ABS_SYMLINK, only the .qlf files are listed in that file. (And when I build with -DINSTALL_QLF=OFF, it seems to have most of the files, but is missing bin/swipl, etc.) I’m seeing a bit of instability in that file, but it takes a long time to re-try the various options.
Weird. I do not use CMAKE_INSTALL_MODE=ABS_SYMLINK and the install manifest looks ok in all variations. Looks like a feature/bug of this CMake option? Why do you care though?
The tricks I use to manage a lot of different installations is
Set the environment variable SWIPL_INSTALL_PREFIX=/home/jan/cmake/@builddir@. This causes ninja install to install in ~/cmake/<builddir>. Once installed, you can run it from there or activate it from the build dir using ../scripts/swipl-activate --installed.
For every build type, create a directory named build.feat1-feat2-...
Run ../scripts/configure. Align the feat terms with the keywords used in this script. Install the direnv utility to have a local environment.
Build using ninja. Normally I simply run src/swipl to play with this particular version. You can connect swipl to the version in this build dir using ../scripts/swipl-activate.
That makes it all easy to manage. The source directories are unaffected. You can ditch a build version simply by removing the build directory and an installed version by removing the directory from ~/cmake. Best, you can quickly switch from the normal release version to the debug version or the ASAN version to analyse issues.
By running the versions from the source dir your Prolog library files are symlinks to the sources, so you can edit them comfortably and test the changes without rebuilding or installing. You should not use the qlf build for that or run Prolog as src/swipl -Dsource.
Currently my default version is built in build.qlf-nosrc and installed (the non-installed version still has the sources). That is a little uncomfortable as you cannot quickly look at the library source. It seems to run quite well though.
If I want to ensure a clean install, I could do rm -rf $(cat install_manifest.txt). (E.g., when switching between INSTALL_QLF settings.) As it is, I can delete a few directories and the binaries, so it’s not a big deal … my suspicion is that it’s a bug in cmake because the manifest used to be correct. (FWIW, I run cmake with -DCMAKE_INSTALL_PREFIX=$HOME/.local)