1 Running setup-plt Executable
The setup-plt executable performs two main services:
Compiling and setting up all (or some of the) collections: When setup-plt is run without any arguments, it finds all of the current collections (see Libraries and Collections) and compiles libraries in each collection.
An optional "info.ss" within the collection can indicate specifically how the collection’s files are to be compiled and other actions to take in setting up a collection, such as creating executables or building documentation. See Controlling setup-plt with "info.ss" Files for more information.
The --clean (or -c) flag to setup-plt causes it to delete existing ".zo" files, thus ensuring a clean build from the source files. The exact set of deleted files can be controlled by "info.ss"; see clean for more information.
The -l flag takes one or more collection names and restricts setup-plt’s action to those collections.
The --mode ⟨mode⟩ flag causes setup-plt to use a ".zo" compiler other than the default compiler, and to put the resulting ".zo" files in a subdirectory (of the usual place) named by ⟨mode⟩. The compiler is obtained by using ⟨mode⟩ as a collection name, finding a "zo-compile.ss" module in that collection, and extracting its zo-compile export. The zo-compile export should be a function like compile; see the "errortrace" collection for an example.
Unpacking ".plt" files: A ".plt" file is a platform-independent distribution archive for software based on PLT Scheme. When one or more file names are provided as the command line arguments to setup-plt, the files contained in the ".plt" archive are unpacked (according to specifications embedded in the ".plt" file) and only collections specified by the ".plt" file are compiled and setup.
Run setup-plt with the -h flag to see a list of all options accepted by the setup-plt executable.
1.1 Controlling setup-plt with "info.ss" Files
To compile a collection’s files to bytecode, setup-plt uses the compile-collection-zos procedure. That procedure, in turn, consults the collection’s "info.ss" file, if it exists, for specific instructions on compiling the collection. See compile-collection-zos for more information on the fields of "info.ss" that it uses, and see "info.ss" File Format for information on the format of an "info.ss" file.
Optional "info.ss" fields trigger additional actions by setup-plt:
scribblings : (listof (cons/c string? list?)) – A list of documents to build. Each document in the list is itself represented as a list, where each document’s list starts with a string that is a collection-relative path to the document’s source file.
More precisely a scribblings entry must be a value that can be generated from an expression matching the following entry grammar:
entry
=
(list doc ...)
doc
=
(list src-string)
|
(list src-string flags)
|
(list src-string flags category)
|
(list src-string flags category name-string)
flags
=
(list mode-symbol ...)
category
=
(list category-symbol)
|
(list category-symbol sort-number)
A document’s list optionally continues with information on how to build the document. If a document’s list contains a second item, it must be a list of mode symbols (described below). If a document’s list contains a third item, it must be a list that categorizes the document (described further below). If a document’s list contains a fourth item, it is a name to use for the generated documentation, instead of defaulting to the source file’s name (sans extension).
Each mode symbol in flags can be one of the following, where only 'multi-page is commonly used:
'multi-page : Generates multi-page HTML output, instead of the default single-page format.
'main-doc : Indicates that the generated documentation should be written into the main installation directory, instead of to a user-specific directory. This mode is the default for a collection that is itself located in the main installation.
'user-doc : Indicates that the generated documentation should be written a user-specific directory. This mode is the default for a collection that is not itself located in the main installation.
'depends-all : Indicates that the document should be re-built if any other document is rebuilt – except for documents that have the 'no-depends-on mode.
'depends-all-main : Indicates that the document should be re-built if any other document is rebuilt that is installed into the main installation – except for documents that have the 'no-depends-on mode.
'always-run : Build the document every time that setup-plt is run, even if none of its dependencies change.
'no-depend-on : Removes the document for consideration for other dependencies. This mode is typically used with 'always-run to avoid unnecessary dependencies that prevent reaching a stable point in building documentation.
'main-doc-root : Designates the root document for the main installation. The document that currently has this mode should be the only one with the mode.
'user-doc-root : Designates the root document for the user-specific documentation directory. The document that currently has this mode should be the only one with the mode.
The category list specifies how to show the document in the root table of contents. The list must start with a symbol, usually one of the following categories, which are ordered as below in the root documentation page:
'getting-started : High-level, introductory documentation.
'language : Documentation for a prominent programming language.
'tool : Documentation for an executable.
'gui-library : Documentation for GUI and graphics libraries.
'net-library : Documentation for networking libraries.
'parsing-library : Documentation for parsing libraries.
'tool-library : Documentation for programming-tool libraries (i.e., not important enough for the more prominent 'tool category).
'interop : Documentation for interoperability tools and libraries.
'library : Documentation for libraries; this category is the default and used for unrecognized category symbols.
'legacy : Documentation for deprecated libraries, languages, and tools.
'experimental : Documentation for an experimental language or library.
'other : Other documentation.
'omit : Documentation that should not be listed on the root page.
If the category list has a second element, it must be a real number that designates the manual’s sorting position with the category; manuals with the same sorting position are ordered alphabetically. For a pair of manuals with sorting numbers n and m, the groups for the manuals are separated by space if (truncate (/ n 10))and (truncate (/ m 10)) are different.
mzscheme-launcher-names : (listof string?) – A list of executable names to be generated in the installation’s executable directory to run MzScheme-based programs implemented by the collection. A parallel list of library names must be provided by mzscheme-launcher-libraries or mzscheme-launcher-flags.
For each name, a launching executable is set up using make-mzscheme-launcher. The arguments are -l- and ⟨colls⟩/.../⟨file⟩, where ⟨file⟩ is the file named by mzscheme-launcher-libraries and ⟨colls⟩/... are the collections (and subcollections) of the "info.ss" file.
In addition,
(build-path (collection-path ⟨colls⟩ ...) ⟨suffixless-file⟩))
is provided for the optional aux argument (for icons, etc.) to make-mzscheme-launcher, where where ⟨suffixless-file⟩ is ⟨file⟩ without its suffix.
If mzscheme-launcher-flags is provided, it is used as a list of command-line arguments passed to mzscheme instead of the above default, allowing arbitrary command-line arguments. If mzscheme-launcher-flags is specified together with mzscheme-launcher-libraries, then the flags will override the libraries, but the libraries can still be used to specify a name for build-aux-from-path (to find related information like icon files etc).
mzscheme-launcher-libraries : (listof path-string?) – A list of library names in parallel to mzscheme-launcher-names.
mzscheme-launcher-flags : (listof string?) – A list of command-line flag lists, in parallel to mzscheme-launcher-names.
mred-launcher-names : (listof string?) – Like mzscheme-launcher-names, but for MrEd-based executables. The launcher-name list is treated in parallel to mred-launcher-libraries and mred-launcher-flags.
mred-launcher-libraries : (listof path-string?) – A list of library names in parallel to mred-launcher-names.
mred-launcher-flags : (listof string?) – A list of command-line flag lists, in parallel to mred-launcher-names.
install-collection : path-string? – A library module relative to the collection that provides installer. The installer procedure accepts either one or two arguments. The first argument is a directory path to the parent of the PLT installation’s "collects" directory; the second argument, if accepted, is a path to the collection’s own directory. The procedure should perform collection-specific installation work, and it should avoid unnecessary work in the case that it is called multiple times for the same installation.
pre-install-collection : path-string? – Like install-collection, except that the corresponding installer is called before the normal ".zo" build, instead of after. The provided procedure should be named pre-installer in this case, so it can be provided by the same file that provides an installer.
post-install-collection : path-string? – Like install-collection. It is called right after the install-collection procedure is executed. The only difference between these is that the --no-install flag can be used to disable the previous two installers, but not this one. It is therefore expected to perform operations that are always needed, even after an installation that contains pre-compiled files. The provided procedure should be named post-installer in this case, so it can be provided by the same file that provides the previous two.
clean : (listof path-string?) – A list of pathnames to be deleted when the --clean or -c flag is passed to setup-plt. The pathnames must be relative to the collection. If any path names a directory, each of the files in the directory are deleted, but none of the subdirectories of the directory are checked. If the path names a file, the file is deleted. The default, if this flag is not specified, is to delete all files in the "compiled" subdirectory, and all of the files in the platform-specific subdirectory of the compiled directory for the current platform.
Just as compiling ".zo" files will compile each module used by a compiled module, deleting a module’s compiled image will delete the ".zo" of each module that is used by the module. More specifically, used modules are determined when deleting a ".dep" file, which would have been created to accompany a ".zo" file when the ".zo" was built by setup-plt. If the ".dep" file indicates another module, that module’s ".zo" is deleted only if it also has an accompanying ".dep" file. In that case, the ".dep" file is deleted, and additional used modules are deleted based on the used module’s ".dep" file, etc. Supplying a specific list of collections to setup-plt disables this dependency-based deletion of compiled files.