I think swipl.home in bin, i.e., the one with dot-dot, is ignored. The one in the parent folder (dot only) is actually read.
Using swipl.home is part of SWI-Prolog’s search for its home directory if it is installed in a relocatable tree such as in Windows. The executable tries to find itself (easy on Windows) and checks for the existence of the file swipl.home in the parent directory of where the executable lives. The path it finds in this location contains the relative location of the home. So
- find executable
- resolve
../swipl.homerelative to the directory holding the executable - If found, read it and interpret the content as the relative location (to the directory holding
swipl.home. - Verify this directory contains
boot.prc.
I understand. The reason I ask is a bit different. After compilation of swipl-devel, there are two swipl.home’s, one is in build, the other one is in build/src, see here:
Matthias@DESKTOP-A2T8IFC MINGW64 ~/swipl-devel/build/src
$ ls
CMakeFiles SWIPLConfigVersion.cmake defatom.exe libswipl-win.dll.a mkvmi.exe pl-atom.ih swipl-ld.exe swipl.exe version.h
CTestTestfile.cmake cmake_install.cmake dot.txt libswipl.dll parms.h pl-funct.ic swipl-win.exe swipl.home vmi-metadata.h
SWIPLConfig.cmake config.h dotdot.txt libswipl.dll.a pl-atom.ic pl-funct.ih swipl.1 swipl.pc win32
That swipl.home is in the same directory as swipl.exe (not in its parent directory). And I think this one is ignored. Would it make sense to consult this, as well? Either before or after the swipl.home in the parent.
The one in build is used by src/swipl[.exe]. The one in build/src may not be needed anymore. I don’t see what use is there in consulting it.
A use case would be MSYS2 again, consider MinGW-W64: Binaries such as swipl.exe go into /mingw64/bin, normally via a symbolic link. /mingw64 is like /usr under Linux. Now, Windows is bad in symbolic links. So the cmake installer actually copies swipl.exe from /mingw64/lib/swipl/bin etc. to /mingw64/bin. However, in that place, swipl.exe does not find its ressources which are still in /mingw64/lib/swipl/bin, so reading it from swipl.home would be handy.
However, at the moment, swipl.home would need to be put into the parent of /mingw64/bin, that is, /mingw64/swipl.home, and that is a bit odd, would be prettier to put it directly next to /mingw64/bin/swipl.exe, i.e., /mingw64/bin/swipl.home.
Given that there is a swipl.home with content “.” in build/src, I was wondering if it would actually be an option to put a swipl.home in the same folder as swipl.exe.
This was a long story 
I should mention that the problem is not that urgent at the moment because I replaced swipl.exe in /mingw64/bin by a little bash script that does the same as the symbolic link.
Hmmm. I don’t think one typically wants data files in directories for executables. The current design aims at installing SWI-Prolog in a relocatable directory.
Note that finding the home has a number of steps, the last of which is using the compiled-in location. Won’t that be sufficient? Or do we get into trouble because the location at which MSYS is installed may differ?
I try to organize the folders in msys2-swipl as in Linux, i.e. swipl.exe and libswipl.dll in /mingw64/bin, and all the rest, including the many dlls with generic names, in /mingw64/lib/swipl etc.
See here:
I know. It is appreciated The compiled-in HOME is defined in cmake/Params.cmake. A start script replacing the function of a symbolic link is probably as good as it gets 
The start script (/mingw64/bin/swipl) currently looks like this:
#!/usr/bin/bash
/mingw64/swipl/bin/amd64-windows/swipl $@
Note the name of the architecture, amd64-windows, whereas swi-prolog says, current_prolog_flag(arch, x64-win64). Can you give me a hint where these names come from, especially the second?
The flag is set in Params.cmake, which is initialized from SWIPL_ARCH, defined in Ports.cmake and for specific systems in earlier included files.
It’s actually hardcoded in src/config/win64.h
#define PLARCH “x64-win64”
I’ll see if this can be changed to a default, possibly overridden by cmake.
I see. Most likely it is defined there from the days that the Windows config was mostly hard coded. Ideally it this value should come through params.h which is created by cmake/Params.cmake, which gets the identifier from Ports.cmake. The identifier itself is CPU-OS. This is, notably for Windows, complicated as we have the native OS, but also the various partial Unix emulations such as cygwin and MSYS. Possibly this should use x64-msys2?
I’d rather not invent something new, but just use the setting provided by cmake (i.e., ${CMAKE_HOST_SYSTEM_PROCESSOR}-${CMAKE_HOST_SYSTEM_NAME}, in my case, amd64-windows). As I understand it, the main purpose of prolog flag “arch” is to help swipl finding the dlls of the packages, but I may be wrong.
And I have a vague feeling that this may be incomplete if we are cross-compiling. There’s also CMAKE_SYSTEM_PROCESSOR and CMAKE_SYSTEM_NAME that refer to the target system, not the host.
Overall, I am tempted to wait until MSYS2 has accepted the patches swi-prolog-8.4.3 a bit before suggesting PRs to swipl-devel.
1 Like
Removed the _HOST_. Pushed some cleanup to make more configuration come through CMake as we always did for all other platforms.
1 Like