- documented ~/.scsh-pkg-defaults file,
- other small modifications
This commit is contained in:
parent
06427ff520
commit
31b8d82bd0
|
@ -1,10 +1,11 @@
|
||||||
%% $Id: proposal.tex,v 1.1 2004/02/11 19:42:30 michel-schinz Exp $
|
%% $Id: proposal.tex,v 1.2 2004/02/29 20:00:47 michel-schinz Exp $
|
||||||
|
|
||||||
%% TODO
|
%% TODO
|
||||||
%% - clean up permissions mess
|
%% - clean up permissions mess
|
||||||
|
|
||||||
\documentclass[a4paper,12pt]{article}
|
\documentclass[a4paper,12pt]{article}
|
||||||
|
|
||||||
|
\usepackage[latin1]{inputenc}
|
||||||
\usepackage{a4wide, palatino, url, hyperref}
|
\usepackage{a4wide, palatino, url, hyperref}
|
||||||
|
|
||||||
\newcommand{\file}{\begingroup \urlstyle{tt}\Url}
|
\newcommand{\file}{\begingroup \urlstyle{tt}\Url}
|
||||||
|
@ -14,9 +15,9 @@
|
||||||
\newcommand{\package}[1]{\texttt{#1}}
|
\newcommand{\package}[1]{\texttt{#1}}
|
||||||
\newcommand{\layout}[1]{\texttt{#1}}
|
\newcommand{\layout}[1]{\texttt{#1}}
|
||||||
\newcommand{\location}[1]{\texttt{#1}}
|
\newcommand{\location}[1]{\texttt{#1}}
|
||||||
|
\newcommand{\ident}[1]{\texttt{#1}}
|
||||||
|
|
||||||
\newcommand{\define}[3]{%
|
\newcommand{\define}[3]{%
|
||||||
\vspace{1em}%
|
|
||||||
\noindent%
|
\noindent%
|
||||||
(\texttt{#1} \textit{#2})\hfill\textit{(#3)}\\[0.5em]%
|
(\texttt{#1} \textit{#2})\hfill\textit{(#3)}\\[0.5em]%
|
||||||
}
|
}
|
||||||
|
@ -75,8 +76,8 @@ simplicity, but it is important to keep in mind that versions are
|
||||||
sequences of integers, not strings.
|
sequences of integers, not strings.
|
||||||
|
|
||||||
A specific version of a package is therefore identified by a name and
|
A specific version of a package is therefore identified by a name and
|
||||||
a version. The full name of a version of a package is obtained by
|
a version. The \emph{full name} of a version of a package is obtained
|
||||||
concatenating:
|
by concatenating:
|
||||||
\begin{itemize}
|
\begin{itemize}
|
||||||
\item the name of the package,
|
\item the name of the package,
|
||||||
\item a hyphen `\texttt{-}',
|
\item a hyphen `\texttt{-}',
|
||||||
|
@ -87,12 +88,11 @@ In what follows, the term \emph{package} is often used to designate a
|
||||||
specific version of a package, but this should be clear from the
|
specific version of a package, but this should be clear from the
|
||||||
context.
|
context.
|
||||||
|
|
||||||
\section{Distribution of packages}
|
\section{Distributing packages}
|
||||||
|
|
||||||
Packages are distributed in \texttt{tar} archives, which can
|
Packages are distributed in \texttt{tar} archives, which can
|
||||||
optionally be compressed by \texttt{gzip} or \texttt{bzip2}.
|
optionally be compressed by \texttt{gzip} or \texttt{bzip2}. The name
|
||||||
|
of the archive is composed by appending:
|
||||||
The name of the archive is composed by appending:
|
|
||||||
\begin{itemize}
|
\begin{itemize}
|
||||||
\item the full name of the package,
|
\item the full name of the package,
|
||||||
\item the string \texttt{.tar} indicating that it's a \texttt{tar}
|
\item the string \texttt{.tar} indicating that it's a \texttt{tar}
|
||||||
|
@ -120,7 +120,7 @@ The unpacking directory contains at least the following files:
|
||||||
package.
|
package.
|
||||||
\end{description}
|
\end{description}
|
||||||
|
|
||||||
\section{Downloading and installation of packages}
|
\section{Downloading and installing packages}
|
||||||
|
|
||||||
A package can be installed on a target machine by downloading its
|
A package can be installed on a target machine by downloading its
|
||||||
archive, expanding it and finally running the installation script
|
archive, expanding it and finally running the installation script
|
||||||
|
@ -129,7 +129,7 @@ located in the unpacking directory.
|
||||||
\subsection{Layouts}
|
\subsection{Layouts}
|
||||||
|
|
||||||
The installation script installs files according to some given
|
The installation script installs files according to some given
|
||||||
\emph{layout}. A layout maps abstract locations to concrete
|
\emph{layout}. A layout maps abstract \emph{locations} to concrete
|
||||||
directories on the target machine. For example, a layout could map the
|
directories on the target machine. For example, a layout could map the
|
||||||
abstract location \location{doc}, where documentation is stored, to
|
abstract location \location{doc}, where documentation is stored, to
|
||||||
the directory \file{/usr/local/share/doc/my_package}.
|
the directory \file{/usr/local/share/doc/my_package}.
|
||||||
|
@ -155,9 +155,9 @@ Currently, the following abstract locations are defined:
|
||||||
platform for which packages have been installed, and nothing else.
|
platform for which packages have been installed, and nothing else.
|
||||||
|
|
||||||
\item[\location{doc}] Location containing all the package
|
\item[\location{doc}] Location containing all the package
|
||||||
documentation. This location contains one or more sub-directories
|
documentation. This location contains one or more sub-directories,
|
||||||
which store the documentation in various formats. The contents of
|
one per format in which the documentation is available. The contents
|
||||||
these sub-directories is standardised as follows, to make it easy
|
of these sub-directories is standardised as follows, to make it easy
|
||||||
for users to find the document they need:
|
for users to find the document they need:
|
||||||
\begin{description}
|
\begin{description}
|
||||||
\item[\file{html}] Directory containing the HTML documentation of
|
\item[\file{html}] Directory containing the HTML documentation of
|
||||||
|
@ -166,12 +166,12 @@ Currently, the following abstract locations are defined:
|
||||||
documentation.
|
documentation.
|
||||||
\item[\file{pdf}] Directory containing the PDF documentation of the
|
\item[\file{pdf}] Directory containing the PDF documentation of the
|
||||||
package, if any; this directory should contain at least one file
|
package, if any; this directory should contain at least one file
|
||||||
called \file{<package>.pdf} where \file{<package>} is the name of
|
called \file{<package_name>.pdf} where \file{<package_name>} is
|
||||||
the package.
|
the name of the package.
|
||||||
\item[\file{ps}] Directory containing the PostScript documentation
|
\item[\file{ps}] Directory containing the PostScript documentation
|
||||||
of the package, if any; this directory should contain at least one
|
of the package, if any; this directory should contain at least one
|
||||||
file called \file{<package>.ps} where \file{<package>} is the name
|
file called \file{<package_name>.ps} where \file{<package_name>}
|
||||||
of the package.
|
is the name of the package.
|
||||||
\item[\file{text}] Directory containing the raw textual
|
\item[\file{text}] Directory containing the raw textual
|
||||||
documentation of the package, if any.
|
documentation of the package, if any.
|
||||||
\end{description}
|
\end{description}
|
||||||
|
@ -193,11 +193,11 @@ to a \emph{prefix}, specified at installation time using the
|
||||||
\file{COPYING} which has to be installed in sub-directory
|
\file{COPYING} which has to be installed in sub-directory
|
||||||
\file{license} of the \location{doc} location. If the user chooses
|
\file{license} of the \location{doc} location. If the user chooses
|
||||||
to use the default layout, which maps \location{doc} to directory
|
to use the default layout, which maps \location{doc} to directory
|
||||||
\file{<package_full_name>/doc} (see below), and specifies
|
\file{<package_full_name>/doc} (see §~\ref{sec:scsh-layout}), and
|
||||||
\file{/usr/local/etc/scsh/modules} as a prefix, then the
|
specifies \file{/usr/local/share/scsh/modules} as a prefix, then the
|
||||||
\file{COPYING} file will end up in:
|
\file{COPYING} file will end up in:
|
||||||
\[
|
\[
|
||||||
\underbrace{\mathtt{/usr/local/etc/scsh/modules/}}_{1}%
|
\underbrace{\mathtt{/usr/local/share/scsh/modules/}}_{1}%
|
||||||
\underbrace{\mathtt{foo-1.2/doc/}}_{2}%
|
\underbrace{\mathtt{foo-1.2/doc/}}_{2}%
|
||||||
\underbrace{\mathtt{license/COPYING}}_{3}
|
\underbrace{\mathtt{license/COPYING}}_{3}
|
||||||
\]
|
\]
|
||||||
|
@ -213,16 +213,17 @@ Every installation script comes with a set of predefined layouts which
|
||||||
serve different aims. They are described below.
|
serve different aims. They are described below.
|
||||||
|
|
||||||
\paragraph{The \layout{scsh} layout}
|
\paragraph{The \layout{scsh} layout}
|
||||||
|
\label{sec:scsh-layout}
|
||||||
|
|
||||||
The \layout{scsh} layout is the default layout. It maps all locations
|
The \layout{scsh} layout is the default layout. It maps all locations
|
||||||
to sub-directories of a single directory, called the package
|
to sub-directories of a single directory, called the package
|
||||||
installation directory, which contains all the files of the package
|
installation directory, which contains nothing but the files of the
|
||||||
being installed and nothing else. Its name is simply the full name of
|
package being installed. Its name is simply the full name of the
|
||||||
the package in question, and it resides in the \file{prefix}
|
package in question, and it resides in the \file{prefix} directory.
|
||||||
directory.
|
|
||||||
|
|
||||||
The \layout{scsh} layout maps locations as given in the following
|
The \layout{scsh} layout maps locations as given in the following
|
||||||
table:
|
table, where \file{<package_full_name>} stands for the full name of
|
||||||
|
the package:
|
||||||
\begin{center}
|
\begin{center}
|
||||||
\begin{tabular}{|l|l|}
|
\begin{tabular}{|l|l|}
|
||||||
\hline
|
\hline
|
||||||
|
@ -244,6 +245,7 @@ common operations easy. For example, finding to which package a file
|
||||||
belongs is trivial, as is the removal of an installed package.
|
belongs is trivial, as is the removal of an installed package.
|
||||||
|
|
||||||
\paragraph{The \layout{fhs} layout}
|
\paragraph{The \layout{fhs} layout}
|
||||||
|
\label{sec:fhs-layout}
|
||||||
|
|
||||||
The \layout{fhs} layout maps locations according to the File Hierarchy
|
The \layout{fhs} layout maps locations according to the File Hierarchy
|
||||||
Standard (FHS, see \href{http://www.pathname.com/fhs/}%
|
Standard (FHS, see \href{http://www.pathname.com/fhs/}%
|
||||||
|
@ -285,14 +287,45 @@ using the \cloption{--prefix} option. It also accepts the following
|
||||||
options:
|
options:
|
||||||
\begin{center}
|
\begin{center}
|
||||||
\begin{tabular}{lp{.6\textwidth}}
|
\begin{tabular}{lp{.6\textwidth}}
|
||||||
\cloption{--layout} name & Specifies the layout to use (see \ref{sec:predefined-layouts}) \\
|
\cloption{--layout} name & Specifies the layout to use (see §~\ref{sec:predefined-layouts}). \\
|
||||||
\cloption{--verbose} & Print messages about what is being done. \\
|
\cloption{--verbose} & Print messages about what is being done. \\
|
||||||
\cloption{--dry-run} & Print what actions would be performed to install the package, but do not perform them. \\
|
\cloption{--dry-run} & Print what actions would be performed to install the package, but do not perform them. \\
|
||||||
\cloption{--inactive} & Do not activate package after installing it. \\
|
\cloption{--inactive} & Do not activate package after installing it. \\
|
||||||
\cloption{--non-shared-only} & Only install platform-dependent files, if any. \\
|
\cloption{--non-shared-only} & Only install platform-dependent files, if any. \\
|
||||||
\cloption{--force} & Overwrite existing files during installation. \\
|
\cloption{--force} & Overwrite existing files during installation. \\
|
||||||
|
\cloption{--no-user-defaults} & Don't read user defaults in \file{.scsh-pkg-defaults} (see §~\ref{sec:user-preferences}). \\
|
||||||
\end{tabular}
|
\end{tabular}
|
||||||
\end{center}
|
\end{center}
|
||||||
|
|
||||||
|
\subsubsection{User preferences}
|
||||||
|
\label{sec:user-preferences}
|
||||||
|
|
||||||
|
Users can store default values for the options passed to the
|
||||||
|
installation script by storing them in a file called
|
||||||
|
\file{.scsh-pkg-defaults.scm} residing in their home directory. This
|
||||||
|
file must contain exactly one Scheme expression whose value is an
|
||||||
|
association list. The keys of this list, which must be symbols,
|
||||||
|
identify options and the values specify the default value for these
|
||||||
|
options. The contents of this file is implicitely quasi-quoted.
|
||||||
|
|
||||||
|
The values stored in this file override the default values of the
|
||||||
|
options, but they are in turn overriden by the values specified on the
|
||||||
|
command line of the installation script. Furthermore, it is possible
|
||||||
|
to ask for this file to be completely ignored by passing the
|
||||||
|
\cloption{--no-user-defaults} option to the installation script.
|
||||||
|
|
||||||
|
\begin{example}
|
||||||
|
A \file{.scsh-pkg-defaults} file containing the following:
|
||||||
|
\begin{verbatim}
|
||||||
|
;; Default values for scsh packages installation
|
||||||
|
((layout . "fhs")
|
||||||
|
(prefix . "/usr/local/share/scsh/modules")
|
||||||
|
(verbose . #t))
|
||||||
|
\end{verbatim}
|
||||||
|
specifies default values for the \cloption{--layout},
|
||||||
|
\cloption{--prefix} and \cloption{--verbose} options.
|
||||||
|
\end{example}
|
||||||
|
|
||||||
%% \subsection{Creating images}
|
%% \subsection{Creating images}
|
||||||
|
|
||||||
%% TODO (my current idea is to add support to install-lib to easily
|
%% TODO (my current idea is to add support to install-lib to easily
|
||||||
|
@ -331,24 +364,26 @@ as this forces scsh to search them recursively. This could
|
||||||
scsh packages according to the \layout{fhs} layout in prefix
|
scsh packages according to the \layout{fhs} layout in prefix
|
||||||
directory \file{/usr/local}. The \location{active} location for
|
directory \file{/usr/local}. The \location{active} location for
|
||||||
these packages corresponds to the directory
|
these packages corresponds to the directory
|
||||||
\file{/usr/local/share/scsh/modules}, according to the layout
|
\file{/usr/local/share/scsh/modules}, according to section
|
||||||
specification above.
|
\ref{sec:fhs-layout}.
|
||||||
|
|
||||||
Let's also imagine that there is a user called \texttt{john} on this
|
Let's also imagine that there is a user called \texttt{john} on this
|
||||||
machine, who installs additional scsh packages for himself in his
|
machine, who installs additional scsh packages for himself in his
|
||||||
home directory, using \file{/home/john/scsh-packages} as a prefix.
|
home directory, using \file{/home/john/scsh-packages} as a prefix.
|
||||||
To ease their management, he uses the \layout{scsh} layout. The
|
To ease their management, he uses the \layout{scsh} layout. The
|
||||||
\location{active} location for these packages corresponds to the
|
\location{active} location for these packages corresponds to the
|
||||||
directory \file{/home/john/scsh-packages}, according to the layout
|
directory \file{/home/john/scsh-packages}, according to section
|
||||||
specification above.
|
\ref{sec:scsh-layout}.
|
||||||
|
|
||||||
In order to be able to use scsh packages installed both by the
|
In order to be able to use scsh packages installed both by the
|
||||||
administrator and by himself, user \texttt{john} needs to put both
|
administrator and by himself, user \texttt{john} needs to put both
|
||||||
active directories in his \envvar{SCSH\_LIB\_DIRS} environment
|
active directories in his \envvar{SCSH\_LIB\_DIRS} environment
|
||||||
variable. The value of this variable will therefore be:
|
variable. The value of this variable will therefore be:
|
||||||
|
\begin{small}
|
||||||
\begin{verbatim}
|
\begin{verbatim}
|
||||||
"/usr/local/share/scsh/modules" "/home/john/scsh-packages"
|
"/usr/local/share/scsh/modules" "/home/john/scsh-packages"
|
||||||
\end{verbatim}
|
\end{verbatim}
|
||||||
|
\end{small}
|
||||||
|
|
||||||
Now, in order to use packages \package{foo} and \package{bar} in one
|
Now, in order to use packages \package{foo} and \package{bar} in one
|
||||||
of his script, user \texttt{john} just needs to load their loading
|
of his script, user \texttt{john} just needs to load their loading
|
||||||
|
@ -359,7 +394,7 @@ as this forces scsh to search them recursively. This could
|
||||||
\end{verbatim}
|
\end{verbatim}
|
||||||
\end{example}
|
\end{example}
|
||||||
|
|
||||||
\section{Writing packages}
|
\section{Authoring packages}
|
||||||
|
|
||||||
Once the Scheme and/or C code for a package has been written, the last
|
Once the Scheme and/or C code for a package has been written, the last
|
||||||
step in turning it into a standard package as defined by this proposal
|
step in turning it into a standard package as defined by this proposal
|
||||||
|
@ -370,13 +405,13 @@ to simplify this task a small scsh installation framework is provided.
|
||||||
This framework is composed of several files which are meant to be
|
This framework is composed of several files which are meant to be
|
||||||
included in the package archive. These files are:
|
included in the package archive. These files are:
|
||||||
\begin{description}
|
\begin{description}
|
||||||
\item[\file{install-pkg}] a trivial \texttt{sh} script which launches
|
\item[\file{install-pkg}] A trivial \texttt{sh} script which launches
|
||||||
scsh on the main function of the installation library, passing it
|
scsh on the main function of the installation library, passing it
|
||||||
all the arguments given by the user,
|
all the arguments given by the user.
|
||||||
\item[\file{install-lib.scm}] the code for the installation library,
|
\item[\file{install-lib.scm}] The code for the installation library,
|
||||||
whose public interface is documented below,
|
whose public interface is documented below.
|
||||||
\item[\file{install-lib-module.scm}] Scheme 48 interface and structure
|
\item[\file{install-lib-module.scm}] Scheme 48 interface and structure
|
||||||
definitions for the installation library,
|
definitions for the installation library.
|
||||||
\end{description}
|
\end{description}
|
||||||
|
|
||||||
As explained above, when the \file{install-pkg} script is invoked, it
|
As explained above, when the \file{install-pkg} script is invoked, it
|
||||||
|
@ -387,44 +422,47 @@ does the following:
|
||||||
option),
|
option),
|
||||||
\item load the package definition file, a (Scheme) file called
|
\item load the package definition file, a (Scheme) file called
|
||||||
\file{pkg-def.scm}, which is supplied by the package author and
|
\file{pkg-def.scm}, which is supplied by the package author and
|
||||||
which contains the installation procedure for the package,
|
which contains one or several package definition statements, and
|
||||||
\item install the package which was defined in the previous step.
|
\item install the packages which were defined in the previous step.
|
||||||
\end{enumerate}
|
\end{enumerate}
|
||||||
It is actually possible to define several packages in
|
Most package definition files should contain a single package
|
||||||
\file{pkg-def.scm}, and all will be installed. It should not be often
|
definition, but the ability to define several packages in one file can
|
||||||
useful, though.
|
sometimes be useful.
|
||||||
|
|
||||||
The main job of the package author is therefore to write the package
|
The main job of the package author is therefore to write the package
|
||||||
definition file, \file{pkg-def.scm}.
|
definition file, \file{pkg-def.scm}. This file is mostly composed of a
|
||||||
|
package definition statement, which specifies the name, version and
|
||||||
This file is mostly composed of a package definition statement, which
|
installation code for the package. The package definition statement is
|
||||||
specifies the name, version and installation code for the package. The
|
expressed using the \ident{define-package} form, documented in the
|
||||||
package definition statement is expressed using the
|
next section.
|
||||||
\texttt{define-package} form, defined below.
|
|
||||||
|
|
||||||
\subsection{Installation library}
|
\subsection{Installation library}
|
||||||
\label{sec:install-library}
|
\label{sec:install-library}
|
||||||
|
|
||||||
|
\subsubsection{Package definition}
|
||||||
|
|
||||||
\defines{define-package}{name version extension body ...}%
|
\defines{define-package}{name version extension body ...}%
|
||||||
Define a package to be installed. \param{Name}, a string, is the
|
Define a package to be installed. \param{Name} (a string) is the
|
||||||
package name, \param{version} its version (a list of integers),
|
package name, \param{version} (a list of integers) is its version,
|
||||||
\param{extensions} is an association list of extensions (see below),
|
\param{extensions} is a list of extensions (see below), and
|
||||||
and \param{body} is the list of statements to be evaluated in order to
|
\param{body} is the list of statements to be evaluated in order to
|
||||||
install the package.
|
install the package.
|
||||||
|
|
||||||
The installation statements typically use functions of the
|
The installation statements typically use functions of the
|
||||||
installation library in order to install files in their target
|
installation library in order to install files in their target
|
||||||
location. The functions currently exported are presented in the
|
location. The available functions are presented below.
|
||||||
remainder of this section.
|
|
||||||
|
|
||||||
\param{Extensions} is currently used only to specify additional
|
\param{Extensions} is currently used only to specify additional
|
||||||
command-line arguments, but in the future it could serve other
|
command-line arguments, but in the future it could serve other
|
||||||
purposes. It consists in a list of pairs, each one composed of a
|
purposes. It consists in a list of lists, each one starting with a
|
||||||
symbol identifying the extension, and extension-specific parameters.
|
symbol identifying the extension, followed by extension-specific
|
||||||
|
parameters.
|
||||||
|
|
||||||
\begin{description}
|
\begin{description}
|
||||||
\item[options] enables the script to define additional command-line
|
\item[options] enables the script to define additional command-line
|
||||||
options. It accepts nine parameters in total, with the last three
|
options. It accepts nine parameters in total, with the last three
|
||||||
being optional. These parameters are described below, in the order
|
being optional. The description of these parameters follows, in the
|
||||||
in which they should appear:
|
order in which they should appear:
|
||||||
\begin{description}
|
\begin{description}
|
||||||
\item[\param{name}] (a symbol) is the name of the option, without
|
\item[\param{name}] (a symbol) is the name of the option, without
|
||||||
the initial double hyphen (\verb|--|),
|
the initial double hyphen (\verb|--|),
|
||||||
|
@ -436,14 +474,15 @@ symbol identifying the extension, and extension-specific parameters.
|
||||||
requires an argument or not,
|
requires an argument or not,
|
||||||
\item[\param{optional-arg?}] (a boolean) says whether this option's
|
\item[\param{optional-arg?}] (a boolean) says whether this option's
|
||||||
argument can be omitted or not,
|
argument can be omitted or not,
|
||||||
\item[\param{default}] is the default value for the option,
|
\item[\param{default}] (anything) is the default value for the
|
||||||
|
option,
|
||||||
\item[\param{parser}] (a function from string to anything) parses
|
\item[\param{parser}] (a function from string to anything) parses
|
||||||
the option, i.e. turns its string representation into its internal
|
the option, i.e. turns its string representation into its internal
|
||||||
value,
|
value,
|
||||||
\item[\param{unparser}] (a function from anything to string) turns
|
\item[\param{unparser}] (a function from anything to string) turns
|
||||||
the internal representation of the option into a string,
|
the internal representation of the option into a string,
|
||||||
\item[\param{transformer}] is a function taking the current value of
|
\item[\param{transformer}] is a function taking the current value of
|
||||||
the option, the value submitted by the user and returning its new
|
the option, the value given by the user and returning its new
|
||||||
value.
|
value.
|
||||||
\end{description}
|
\end{description}
|
||||||
By default, \param{parser} and \param{unparser} are the identity
|
By default, \param{parser} and \param{unparser} are the identity
|
||||||
|
@ -452,6 +491,8 @@ symbol identifying the extension, and extension-specific parameters.
|
||||||
option is simply replaced by the one given).
|
option is simply replaced by the one given).
|
||||||
\end{description}
|
\end{description}
|
||||||
|
|
||||||
|
\subsubsection{Content installation}
|
||||||
|
|
||||||
\definep{install-file}{file location [target-dir]}%
|
\definep{install-file}{file location [target-dir]}%
|
||||||
Install the given \param{file} in the sub-directory \param{target-dir}
|
Install the given \param{file} in the sub-directory \param{target-dir}
|
||||||
(which must be a relative directory) of the given \param{location}.
|
(which must be a relative directory) of the given \param{location}.
|
||||||
|
@ -465,11 +506,13 @@ specifies the name of the source file, and its second element the name
|
||||||
it will have once installed. The second element must be a simple file
|
it will have once installed. The second element must be a simple file
|
||||||
name, without any directory part.
|
name, without any directory part.
|
||||||
|
|
||||||
\definep{install-file}{file-list location [target-dir]}%
|
\vspace{1em}
|
||||||
Like install-file but for several files, which are specified as a
|
\definep{install-files}{file-list location [target-dir]}%
|
||||||
list. Each element in the list can be either a simple string or a
|
Like \ident{install-file} but for several files, which are specified
|
||||||
|
as a list. Each element in the list can be either a simple string or a
|
||||||
pair, as explained above.
|
pair, as explained above.
|
||||||
|
|
||||||
|
\vspace{1em}
|
||||||
\definep{install-directory}{directory location [target-dir]}%
|
\definep{install-directory}{directory location [target-dir]}%
|
||||||
Install the given \param{directory} and all its contents, including
|
Install the given \param{directory} and all its contents, including
|
||||||
sub-directories, in sub-directory \param{target-dir} of
|
sub-directories, in sub-directory \param{target-dir} of
|
||||||
|
@ -479,17 +522,22 @@ but for complete hierarchies.
|
||||||
Notice that \param{directory} will be installed as a sub-directory of
|
Notice that \param{directory} will be installed as a sub-directory of
|
||||||
\param{target-dir}.
|
\param{target-dir}.
|
||||||
|
|
||||||
|
\vspace{1em}
|
||||||
\definep{install-directories}{dir-list location [target-dir]}%
|
\definep{install-directories}{dir-list location [target-dir]}%
|
||||||
Install several directories in one go.
|
Install several directories in one go.
|
||||||
|
|
||||||
|
\vspace{1em}
|
||||||
\definep{install-directory-contents}{directory location [target-dir]}%
|
\definep{install-directory-contents}{directory location [target-dir]}%
|
||||||
Install the \emph{contents} of the given \param{directory} in
|
Install the contents of the given \param{directory} in sub-directory
|
||||||
sub-directory \param{target} of \param{location}.
|
\param{target} of \param{location}.
|
||||||
|
|
||||||
|
\vspace{1em}
|
||||||
\definep{install-string}{string location [target-dir]}%
|
\definep{install-string}{string location [target-dir]}%
|
||||||
Install the contents of \param{string} in sub-directory
|
Install the contents of \param{string} in sub-directory
|
||||||
\param{target-dir} of \param{location}.
|
\param{target-dir} of \param{location}.
|
||||||
|
|
||||||
|
\subsubsection{Queries}
|
||||||
|
|
||||||
\definep{get-directory}{location install?}%
|
\definep{get-directory}{location install?}%
|
||||||
Get the absolute name of the directory to which the current layout
|
Get the absolute name of the directory to which the current layout
|
||||||
maps the abstract \param{location}. If \param{install?} is true, the
|
maps the abstract \param{location}. If \param{install?} is true, the
|
||||||
|
@ -501,29 +549,34 @@ The distinction between installation-time and usage-time directories
|
||||||
is necessary to support staged installation, as performed by package
|
is necessary to support staged installation, as performed by package
|
||||||
managers like Debian's APT.
|
managers like Debian's APT.
|
||||||
|
|
||||||
|
\vspace{1em}
|
||||||
\definep{get-option-value}{option}%
|
\definep{get-option-value}{option}%
|
||||||
Return the value of the given command-line \param{option} (a symbol).
|
Return the value of the given command-line \param{option} (a symbol).
|
||||||
This can be used to get the value of predefined options (like
|
This can be used to get the value of predefined options (like
|
||||||
\cloption{--dry-run}) or package-specific options.
|
\cloption{--dry-run}) or package-specific options.
|
||||||
|
|
||||||
|
\subsubsection{Load script generation}
|
||||||
|
|
||||||
\definep{with-output-to-load-script*}{thunk}%
|
\definep{with-output-to-load-script*}{thunk}%
|
||||||
Evaluate \param{thunk} with the current output opened on the loading
|
Evaluate \param{thunk} with the current output opened on the loading
|
||||||
script of the current package. If this script was already existing,
|
script of the current package. If this script was already existing,
|
||||||
its previous contents will be deleted.
|
its previous contents is deleted.
|
||||||
|
|
||||||
|
\vspace{1em}
|
||||||
\defines{with-output-to-load-script}{body ...}%
|
\defines{with-output-to-load-script}{body ...}%
|
||||||
Syntactic sugar for \param{with-output-to-load-script*}.
|
Syntactic sugar for \ident{with-output-to-load-script*}.
|
||||||
|
|
||||||
|
\vspace{1em}
|
||||||
\definep{write-to-load-script}{s-expression}%
|
\definep{write-to-load-script}{s-expression}%
|
||||||
Pretty-print the \param{s-expression} to the loading script of the
|
Pretty-print the \param{s-expression} to the loading script of the
|
||||||
current package. If this script was already existing, its previous
|
current package. If this script was already existing, its previous
|
||||||
contents will be deleted.
|
contents is deleted.
|
||||||
|
|
||||||
\begin{example}
|
\begin{example}
|
||||||
A typical package definition file for a simple package called
|
A typical package definition file for a simple package called
|
||||||
\package{my\_package} whose version is 1.2 could look like this:
|
\package{pkg} whose version is 1.2 could look like this:
|
||||||
\begin{verbatim}
|
\begin{verbatim}
|
||||||
(define-package "my_package" (1 2) ()
|
(define-package "pkg" (1 2) ()
|
||||||
(install-file "load.scm" 'base)
|
(install-file "load.scm" 'base)
|
||||||
(install-directory-contents "scheme" 'scheme)
|
(install-directory-contents "scheme" 'scheme)
|
||||||
(install-file ("LICENSE" . "COPYING") 'doc)
|
(install-file ("LICENSE" . "COPYING") 'doc)
|
||||||
|
@ -531,24 +584,21 @@ contents will be deleted.
|
||||||
\end{verbatim}
|
\end{verbatim}
|
||||||
|
|
||||||
With such a definition, invoking the installation script with
|
With such a definition, invoking the installation script with
|
||||||
\file{/usr/local/} as prefix and \layout{fhs} as layout would have
|
\file{/usr/local/} as prefix and \layout{fhs} as layout has the
|
||||||
the following effects:
|
following effects:
|
||||||
\begin{enumerate}
|
\begin{enumerate}
|
||||||
\item The base directory
|
\item The base directory \file{/usr/local/share/scsh/modules/pkg-1.2}
|
||||||
\file{/usr/local/share/scsh/modules/my_package-1.2} would be created
|
is created and file \file{load.scm} is copied to it.
|
||||||
and file \file{load.scm} would be copied to it.
|
\item All the contents of the directory called \file{scheme} is copied
|
||||||
\item All the contents of the directory called \file{scheme} would be
|
to directory \file{/usr/local/share/scsh/modules/pkg-1.2/scheme}
|
||||||
copied to directory
|
which is created before, if needed.
|
||||||
\file{/usr/local/share/scsh/modules/my_package-1.2/scheme} which
|
\item File \file{LICENSE} is copied to directory
|
||||||
would be created before, if needed.
|
\file{/usr/local/share/doc/pkg-1.2/} with name \file{COPYING}.
|
||||||
\item File \file{LICENSE} would be copied to directory
|
\item All the contents of the directory called \file{doc} is copied to
|
||||||
\file{/usr/local/share/doc/my_package-1.2/} with name
|
directory \file{/usr/local/share/doc/pkg-1.2/}
|
||||||
\file{COPYING}.
|
\item The package is activated by creating a symbolic link with name
|
||||||
\item All the contents of the directory called \file{doc} would be
|
\file{/usr/local/share/scsh/modules/pkg} pointing to
|
||||||
copied to directory \file{/usr/local/share/doc/my_package-1.2/}
|
\file{./pkg-1.2}
|
||||||
\item The package would be activated by creating a symbolic link with
|
|
||||||
name \file{/usr/local/share/scsh/modules/my_package} pointing to
|
|
||||||
\file{./my_package-1.2}
|
|
||||||
\end{enumerate}
|
\end{enumerate}
|
||||||
\end{example}
|
\end{example}
|
||||||
|
|
||||||
|
@ -561,8 +611,8 @@ Fortunately, the GNU Autoconf system simplifies the management of
|
||||||
these problems, and authors of scsh packages containing C code are
|
these problems, and authors of scsh packages containing C code are
|
||||||
strongly encouraged to use it.
|
strongly encouraged to use it.
|
||||||
|
|
||||||
Integrating Autoconf into the installation procedure should not be a
|
%% Integrating Autoconf into the installation procedure should not be a
|
||||||
major problem thanks to scsh's ability to run separate programs.
|
%% major problem thanks to scsh's ability to run separate programs.
|
||||||
|
|
||||||
\section{Packaging packages}
|
\section{Packaging packages}
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue