Good behaviour in SWI-Prolog library contribution

Hello all,

I’m wondering what the appropriate way to do pull requests to SWI-Prolog. A number of elements which ship under ‘library’ are also in a pack. Should pull requests be made to the pack or to the library?

In particular I was intending to float two contributions to ‘apply’, an extended convlist to more arguments, and a mapm which is basically like scanl but only chaining the final argument (which is much handier for use in DCGs).

1 Like

The pack/pckage terminology is a bit shaky :frowning: The core distribution consists of swipl-devel.git and git submodules that are registered under the packages directory (and a few more git submodules I won’t discuss now). Most of the submodules under packages install Prolog files in library in the final product.

So, you have to figure out whether it is the main git repo or some (and which) package provides a particular library file. If you built from git the build creates a directory home in the CMake build directory where it populates a SWI-Prolog home directory as it will ultimately be installed. This allows running src/swipl from the build directory without installing it, which is great for developing the system :slight_smile: When doing so on a system that supports symbolic links, the files in e.g., home/library are symlinks to the source tree. Now we see

ls -l home/library/apply.pl 
lrwxrwxrwx 1 janw janw 25 Sep 27 10:23 home/library/apply.pl -> ../../../library/apply.pl

so this one comes from the main repo. We can also try this to see time.pl is supplied by the clib package.

ls -l home/library/time.pl 
lrwxrwxrwx 1 janw janw 30 Sep 27 10:23 home/library/time.pl -> ../../../packages/clib/time.pl

See How to submit patches? for creating a PR, notably for the submodules.

3 Likes