The first
consideration is what extension to use for the source files. Tradition
calls for .pl, but conflicts with Perl force the use of
another extension on systems where extensions have global meaning, such
as MS-Windows. On such systems .pro is the common
alternative. On MS-Windows, the alternative extension is stored in the
registry key
HKEY_CURRENT_USER/Software/SWI/Prolog/fileExtension or
HKEY_LOCAL_MACHINE/Software/SWI/Prolog/fileExtension. All
versions of SWI-Prolog load files with the extension .pl as
well as with the registered alternative extension without explicitly
specifying the extension. For portability reasons we propose the
following convention:
- If there is no conflict
- because you do not use a conflicting application or the system does not
force a unique relation between extension and application, use
.pl.
- With a conflict
- choose
.pro and use this extension for the files you want
to load through your file manager. Use
.pl for all other files for maximal portability.
Large projects
are generally composed of sub-projects, each using its own directory or
directory structure. If nobody else will ever touch your files and you
use only one computer, there is little to worry about, but this is
rarely the case with a large project.
To improve portability, SWI-Prolog uses the POSIX notation for
filenames, which uses the forward slash (//\\\
Portable code should use prolog_to_os_filename/2
to convert computed paths into system paths when constructing commands
for shell/1
and friends.
Thanks to Quintus, Prolog adapted an extensible mechanism for
searching files using file_search_path/2.
This mechanism allows for comfortable and readable specifications.
Suppose you have extensive library packages on graph algorithms, set
operations and GUI primitives. These sub-projects are likely candidates
for re-use in future projects. A good choice is to create a directory
with sub-directories for each of these sub-projects.
Next, there are three options. One is to add the sub-projects to the
directory hierarchy of the current project. Another is to use a
completely dislocated directory. Third, the sub-project can be added to
the SWI-Prolog hierarchy. Using local installation, a typical file_search_path/2
is:
:- prolog_load_context(directory, Dir),
asserta(user:file_search_path(myapp, Dir)).
user:file_search_path(graph, myapp(graph)).
user:file_search_path(ui, myapp(ui)).
When using sub-projects in the SWI-Prolog hierarchy, one should use
the path alias swi as basis. For a system-wide
installation, use an absolute path.
Extensive sub-projects with a small well-defined API should define a
load file with calls to use_module/1
to import the various library components and export the API.
