I admit that I don’t understand all the details, but I am happy with the first sentence.
Move on. Great work.
Edit: Tests are passing now (except for semweb:turtle and semweb:ntripes that fail because of the large Unicode codepoints IIRC).
One more little thing. IIUC, after having run cmake and ninja from swipl-devel/build, there’s a fully functioning system in build/src, so that I can run the following commands:
mkdir build
cd build
cmake -G Ninja ..
ninja
src/swipl
?- check_installation.
?- pack_install(environ).
The last command fails because c_libdir is not set properly for the build environment.
6 ?- pack_install(environ).
% Contacting server at https://www.swi-prolog.org/pack/query ... ok
Install environ@1.0 from http://www.swi-prolog.org/download/pack/environ-1.0.tgz Y/n?
make_directory: c:/users/matth/appdata/local/swi-prolog/pack/environ
% Contacting server at https://www.swi-prolog.org/pack/query ... ok
% "environ-1.0.tgz" was downloaded 106 times
Package: environ
Title: Demo package with C code, fetching the program environment
Installed version: 1.0
Author: Jan Wielemaker <jan@swi-prolog.org>
Home page: http://www.swi-prolog.org/howto/ForeignPack.html
Download URL: http://www.swi-prolog.org/download/pack/environ-*.tgz
Install "environ-1.0.tgz" (1,084 bytes) Y/n?
ERROR: C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lswipl: No such file or directory
ERROR: collect2.exe: error: ld returned 1 exit status
ERROR: make: *** [Makefile:9: lib/x64-win64/environ.dll] Error 1
% gcc -fPIC -pthread -I"c:/msys64/home/matthias/swipl-devel/build/home/include" -c -o c/environ.o c/environ.c
% mkdir -p lib/x64-win64
% C:/msys64/mingw64/bin/cc.exe -shared -L"c:/msys64/home/matthias/swipl-devel/build/home/bin" -o lib/x64-win64/environ.dll c/environ.o -lswipl
ERROR: Process "process(c:/msys64/usr/bin/make.exe,[])": exit status: 2
Note the -L"c:/msys64/home/matthias/swipl-devel/build/home/bin" that should read as -L"c:/msys64/home/matthias/swipl-devel/build/src".
This applies only for the build environment. Things work well after installation (i.e. ninja install and then invoking swipl.exe from the installation folder).
I guess c_libdir needs to be tweaked from boot/build_home.pl, doesn’t it?
The problem is not seen under Linux since there’s not need to link modules to libswipl.so under linux.
I see. The flags are generated from library/prolog_config.pl. This can be hooked using prolog:runtime_config(Flag, Value). Probably the best option is to add this hook to the build-tree init file that is in boot/build_home.pl. I think you can figure that out 
The thing is that prolog:runtime_config(Flag, Value) already returns the correct settings.
src/swipl
? - prolog:runtime_config(Flag, Value).
Flag = c_libdir,
Value = ‘c:/msys64/home/matthias/swipl-devel/build/src’.
For some reason, the setting is not used in pack_rebuild.
This is working:
1 ?- assert(prolog:build_environment('CC', 'C:/msys64/mingw64/bin/gcc.exe')).
true.
2 ?- assert(prolog:build_environment('LDSOFLAGS', '-shared -L"C:\\msys64\\home\\Matthias\\swipl-devel\\build\\src"')).
true.
3 ?- pack_rebuild(environ).
% rm -f c/environ.o
% rm -f lib/x64-win64/environ.dll
% C:/msys64/mingw64/bin/gcc.exe -fPIC -pthread -I"c:/msys64/home/matthias/swipl-devel/build/home/include" -c -o c/environ.o c/environ.c
% mkdir -p lib/x64-win64
% C:/msys64/mingw64/bin/cc.exe -shared -L"C:\msys64\home\Matthias\swipl-devel\build\src" -o lib/x64-win64/environ.dll c/environ.o -lswipl
% make: Nothing to be done for 'check'.
% make: Nothing to be done for 'install'.
Seems pack_install/2 follows a different route. See library/build/tools.pl, def_environment/3, clause at line 307. This code deals with setting up the build infrastructure for either make or cmake. Needs a little puzzle to deal with the many configurations 
A PR is on it’s way. I need to find a solution that does not break swipl at the installation folder.
Works! Thanks!
I have one more little “wish” (not strictly an error or missing feature). I think we had a conversation about this before. In Ports.cmake, SWIPL_ARCH is set for the different architectures, and a default is based on CMAKE_SYSTEM_PROCESSOR and CMAKE_SYSTEM_NAME.
if(APPLE)
include(port/Darwin)
elseif(WIN32)
include(port/Windows)
elseif(EMSCRIPTEN)
include(port/Emscripten)
elseif(ANDROID)
include(port/Android)
endif()
# Architecture id (Prolog flag `arch`, architecture subdirs)
if(NOT SWIPL_ARCH)
string(TOLOWER ${CMAKE_SYSTEM_PROCESSOR}-${CMAKE_SYSTEM_NAME}
SWIPL_ARCH)
endif()
For Windows, SWIPL_ARCH is hardcoded in ports/Windows.cmake:
if(CMAKE_SIZEOF_VOID_P EQUAL 8)
add_compile_options(-DWIN64)
set(WIN64 1)
set(WIN_PROGRAM_FILES "Program Files")
set(SWIPL_ARCH x64-win64)
else()
set(WIN_PROGRAM_FILES "Program Files (x86)")
set(SWIPL_ARCH i386-win32)
endif()
I wonder if the hard-coded names can be omitted, so that the default based on CMAKE_SYSTEM_PROCESSOR and CMAKE_SYSTEM_NAME is taken under Windows, like under Linux (on my system, this is amd64-windows). It might simplify finding e.g. libswipl.dll from external programs, because they can rely on the cmake settings and do not have to memorize the hard-coded names of the architecture.
I admit that it’s only a little thing, but maybe you could consider it.
I have my doubts. First of all, it will break existing binary packages. Second, I’m not sure how stable these results are. In my cross compiling environment CMAKE_SYSTEM_PROCESSOR is empty.
Ideally we provide a CMake include file that provides all you need at a well known place. This already happens for non-Windows systems (at <prefix>/lib/cmake/swipl)
I also have some CMake script laying around that calls swipl to setup the targets using swipl --dump-runtime-variables. If you just want the architecture, use swipl --arch.
I see your points.
Hi. Is this release supposed to have the WASM support? I can see the WASM documentation but no WASM Javascript.
-Thanks
Depends what you consider “support”. Yes, the WASM build process is integrated and documented and yes, the high level wrapper that makes Prolog easily accessible from JavaScript and allows Prolog to call JavaScript and interact with the browser is all there. I think these interfaces are stable enough to start using them. There is a node package swipl-wasm by @rla.
As noted in the WASM wiki and discussion, there is still a lot to wish for. For now I need to do a work that pays the bills, so the WASM version stalls around here unless people contribute code, examples, documentation, etc., or find some way to make its development pay the bills