Commit afbebde3 authored by Francois-Rene Rideau's avatar Francois-Rene Rideau
Browse files
parents 5e0507d5 8bb7dcea
......@@ -48,13 +48,22 @@
Publisher = {Springer}
}
@Article{XCVB,
Article{XCVB,
Author = {Fran\c{c}ois-Ren\'{e} Rideau and Spencer Brody},
Title = {{XCVB}: Improving Modularity for {C}ommon {L}isp},
Booktitle={International Lisp Conference},
URL="http://common-lisp.net/projects/xcvb/",
Year = {2009}
}
@InProceedings{XCVB,
author = {Fran\c{c}ois-Ren\'{e} Rideau and Spencer Brody},
title = {{XCVB}: an {eXtensible} {Component} {Verifier} and {Builder}
for {Common} {Lisp}},
URL = "http://common-lisp.net/projects/xcvb/",
booktitle = {International Lisp Conference},
year = 2009
}
@Misc{Software-Irresponsibility,
Author={Fran\c{c}ois-Ren\'{e} Rideau},
......@@ -154,3 +163,29 @@
pages = {1049--1096},
url = "http://www.cs.umd.edu/~mwh/papers/HicksNettles03.html"
}
@article{Feldman79,
author = {Stuart I. Feldman},
title = {Make--A Program for Maintaining Computer Programs},
journal = {Software Practice and Experience},
volume = {9},
number = {4},
year = {1979},
pages = {255-65},
bibsource = {DBLP, http://dblp.uni-trier.de}
}
@Article{Sidebotham98,
author = {Bob Sidebotham},
title = {Software Construction with {Cons}},
journal = {Perl Journal},
year = 1998,
volume = 3,
number = 1}
@Misc{scons,
key = {SCons},
title = {SCons website},
url = {www.scons.org}}
......@@ -64,10 +64,10 @@ such as distributing software, managing bugs, connecting people,
solving dependency versioning issues (aka ``DLL hell''), etc.
\subsection{Analogy with make} % {\make} looks weird here
\subsection{Analogy with \texttt{make}} % {\make} looks weird here
\label{sec:analogy-with-make}
It is conventional to explain {\ASDF} as the {\CL} analog of {\make}:
It is conventional to explain {\ASDF} as the {\CL} analog of {\make}~\cite{Feldman79}:
both are used to build software, compile documentation, run tests.
However, the analogy is very limited:
while both {\ASDF} and {\make} are used for such high-level building tasks,
......
% \section{History}
% \label{sec:history}
\begin{itemize}
\item LOAD scripts
\item Deep background --- Symbolics, etc. defsystems?
\item MK-DEFSYSTEM
\item ASDF Classic --- Can we interview Dan Barlow for information?
\item Mudballs (did this ever go anywhere?)
\item XCVB
\item ASDF2
\begin{itemize}
\item Gary King for maintenance efforts before {\fare} took over.
\item {\fare} era
\end{itemize}
\end{itemize}
% \begin{itemize}
% \item LOAD scripts
% \item Deep background --- Symbolics, etc. defsystems?
% \item MK-DEFSYSTEM
% \item ASDF Classic --- Can we interview Dan Barlow for information?
% \item Mudballs (did this ever go anywhere?)
% \item XCVB
% \item ASDF2
% \begin{itemize}
% \item Gary King for maintenance efforts before {\fare} took over.
% \item {\fare} era
% \end{itemize}
% \end{itemize}
\draft{
Anything missing in the above?
}
% \draft{
% Anything missing in the above?
% }
\draft{Symbolics \defsys{} here... Kantrowitz claims that it is a
\emph{procedural}, rather than a structural system definition tool. Cites the
BUILD system~\cite{AITR-874} as a structural tool.}
% \draft{Symbolics \defsys{} here... Kantrowitz claims that it is a
% \emph{procedural}, rather than a structural system definition tool. Cites the
% BUILD system~\cite{AITR-874} as a structural tool.}
\draft{Notes on Symbolics defsystem taken from BUILD AITR unless explicitly noticed otherwise.}
% \draft{Notes on Symbolics defsystem taken from BUILD AITR unless explicitly noticed otherwise.}
\draft{Notes on BUILD:
\begin{itemize}
\item More declarative than other systems;
\item Declarative specification of transformations between \emph{grains} (not
offered by various flavors of \defsys{}.
\item Clear treatment of distinction between macro dependencies (compile-time)
and call dependencies (run-time --- load time in our jargon).
\item Dependencies are described directly, rather than in terms of system
operations. So don't say ``must build this when the other changes,''
instead say ``this module \texttt{macro-calls} these other modules,'' etc.
Necessary system operations are inferred from this information. This
information is called the ``reference level model'' and the ``task level
model'' is derived from it.
\item BUILD is also a plan-then-execute model.
\end{itemize}
}
% \draft{Notes on BUILD:
% \begin{itemize}
% \item More declarative than other systems;
% \item Declarative specification of transformations between \emph{grains} (not
% offered by various flavors of \defsys{}.
% \item Clear treatment of distinction between macro dependencies (compile-time)
% and call dependencies (run-time --- load time in our jargon).
% \item Dependencies are described directly, rather than in terms of system
% operations. So don't say ``must build this when the other changes,''
% instead say ``this module \texttt{macro-calls} these other modules,'' etc.
% Necessary system operations are inferred from this information. This
% information is called the ``reference level model'' and the ``task level
% model'' is derived from it.
% \item BUILD is also a plan-then-execute model.
% \end{itemize}
% }
A key inspiration for ASDF was \mkdefsys{}, Mark Kantrowitz's portable
A key inspiration for ASDF was \mkdefsys{}, Mark Kan\-tro\-witz's portable
\defsys{} facility~\cite{kantrowitz:91}. At the time when \mkdefsys{}
was developed, there was no portable, non-proprietary system definition
facility for Common Lisp, as Lisp moved off special-purpose platforms and onto
facility for {\CL}, as Lisp moved off special-purpose platforms and onto
general-purpose hardware. Prior to this (and substantially prior to a true
\emph{Common} Lisp), there were a number of different system-defining
facilities, notably the Symbolics \defsys{}, but people wanting to
portably define systems had to rely on \texttt{LOAD} scripts and/or
\texttt{REQUIRE}.
facilities, notably the Symbolics \defsys{}~\cite{CHINE-NUAL}\footnote{Cited by Robbins~\cite{AITR-874}}, but people wanting to
portably define systems had to rely on \lisp{LOAD} scripts and/or
\lisp{REQUIRE}.
\draft{Too-specific notes on \mkdefsys{} that need to be winnowed for the
paper....
The \ASDF{} manual~\cite{ASDF-Manual}, discussing \mkdefsys{} as an inspiration,
explains that it was intended to better use \CL{} features (notably CLOS) for
extensibility. \mkdefsys{} is written in pre-CLOS \CL{}. However, we argue
that a primary reason for \ASDF{}'s success was not its CLOS architecture, but
its elegant use of \lisp{*load-truename*} to solve the social problem of
installing and referencing lisp libraries. The problem of \emph{installing}
lisp libraries was not helped by \mkdefsys{}, but was substantially eased by \ASDF{}.
See
Section~\ref{sec:input-locations} for more discussion of this issue.
Some key ideas present in \mkdefsys{}:
\begin{itemize}
\item parametric \texttt{operate-on-system} function.
\item selective recompilation to minimize work
\item declarative system spec --- specify dependencies and components;
\mkdefsys{} infers the procedure.
\item intended to be extensible
\item Use of Unix pathnames as de facto standard --- portability across unix
and mac was punted to logical pathnames.
\item Plan-then-execute. DAG is topologically sorted before anything is done.
\item Manages non-lisp components.
\end{itemize}
\emph{Not} present:
\begin{itemize}
\item Clever use of \texttt{*load-truename*} to locate source files. The
problem of \emph{installing} systems was not helped by \mkdefsys{}. At the
top, \texttt{:SYSTEM}s had to have absolute pathnames.
\item Automatic placement of binary files. I believe this had to be handled
through use of conditional compilation (reader macros) combinated with
telling the system about the binary output names different implementations
assumed. The problem was recognized though. However, on the owner's site,
this problem was handled by the Andrew File System, and something like
ASDF-BINARY-LOCATIONS was supported by allowing users to emulate this
feature of AFS.
\item Use of CLOS. Some of the things done by CLOS method combination in ASDF
are done by special keywords like \texttt{:FINALLY-DO}.
\item System versioning. Version-matching.
\end{itemize}
BUILD~\cite{AITR-874} was a substantially earlier Lisp build system (antedating
\CL{}), and an inspiration behind \mkdefsys{}.
BUILD attempted to be more declarative than \make{} and other predecessors. It
\emph{may} have introduced the notion of creating a complete operation plan
before executing any operations; we are not certain.
Features not taken over into ASDF:
\begin{itemize}
\item \mkdefsys{} had \texttt{:PRIVATE-FILE} as a component type that
could be used for, e.g., user-specific configuration files.
\item You can do package-wrangling in the system definition, instead of coding
package into files.
\item \texttt{:LOAD-ONLY} components.
\end{itemize}
% \draft{Too-specific notes on \mkdefsys{} that need to be winnowed for the
% paper....
% Some key ideas present in \mkdefsys{}:
% \begin{itemize}
% \item parametric \texttt{operate-on-system} function.
% \item selective recompilation to minimize work
% \item declarative system spec --- specify dependencies and components;
% \mkdefsys{} infers the procedure.
% \item intended to be extensible
% \item Use of Unix pathnames as de facto standard --- portability across unix
% and mac was punted to logical pathnames.
% \item Plan-then-execute. DAG is topologically sorted before anything is done.
% \item Manages non-lisp components.
% \end{itemize}
% \emph{Not} present:
% \begin{itemize}
% \item Clever use of \texttt{*load-truename*} to locate source files. The
% problem of \emph{installing} systems was not helped by \mkdefsys{}. At the
% top, \texttt{:SYSTEM}s had to have absolute pathnames.
% \item Automatic placement of binary files. I believe this had to be handled
% through use of conditional compilation (reader macros) combinated with
% telling the system about the binary output names different implementations
% assumed. The problem was recognized though. However, on the owner's site,
% this problem was handled by the Andrew File System, and something like
% ASDF-BINARY-LOCATIONS was supported by allowing users to emulate this
% feature of AFS.
% \item Use of CLOS. Some of the things done by CLOS method combination in ASDF
% are done by special keywords like \texttt{:FINALLY-DO}.
% \item System versioning. Version-matching.
% \end{itemize}
% Features not taken over into ASDF:
% \begin{itemize}
% \item \mkdefsys{} had \texttt{:PRIVATE-FILE} as a component type that
% could be used for, e.g., user-specific configuration files.
% \item You can do package-wrangling in the system definition, instead of coding
% package into files.
% \item \texttt{:LOAD-ONLY} components.
% \end{itemize}
}
% }
%%% Local Variables:
......
......@@ -39,8 +39,8 @@
\newcommand{\system}{\lisp{system}}
\newcommand{\module}{\lisp{module}}
\newcommand{\mkdefsys}{\texttt{MK-DEFSYSTEM}}
\newcommand{\defsys}{\texttt{DEFSYSTEM}}
\newcommand{\mkdefsys}{\texttt{MK-DEF\-SYS\-TEM}}
\newcommand{\defsys}{\texttt{DEF\-SYS\-TEM}}
\newcommand{\CLOSERMOP}{\texttt{CLOSER-MOP}}
\newcommand{\longCL}{Common Lisp}
\newcommand{\CL}{CL}
......@@ -99,6 +99,11 @@ Common Lisp, build infrastructure, interaction design, code evolution.
%\onecolumn % Single column. - for debugging only
\fixme{During final pass, harmonize capitalization. ``lisp'' all either
capitalized or not. Lisp function name capitalization also harmonized (the
\texttt{\\lisp} macro should help here) -- should these names all be capitalized
or all downcased?}
\section{Introduction}
\fixme{Propose we revise this after we've thrashed out the rest of the paper, to
......@@ -1066,87 +1071,113 @@ Documentation is a pain, and is still a weakness of \ASDFii{}.
\subsection{History}
\label{sec:history}
\draft{One paragraph \textbf{only} to discuss the stuff in our history
appendix. Original fodder follows}
\input{history}
\subsection{Related work}
\label{sec:related-works}
\draft{
\begin{itemize}
\item Previous systems:
\begin{itemize}
\item Early {\defsys} versions
\item \texttt{make}
\item \texttt{BUILD}
\item {\mkdefsys}
An interesting question is whether {\mkdefsys} also generated a plan before operating...
\end{itemize}
\item Alternative build systems:
\begin{itemize}
\item McDermott's chunk-based system
\item XCVB
\end{itemize}
\item Systems built on top of {\ASDF}:
\begin{itemize}
\item Multiple software management systems:
\begin{itemize}
\item ASDF-INSTALL
\item clbuild
\end{itemize}
\end{itemize}
\end{itemize}
Non-Lisp:
make
OMake
BUILD TR points out that {\make} does not support modules, so difficult to see
the structure in makefiles. Possibly worth patching this in to earlier
discussion.
BUILD TR claims that \make{} is \emph{not} a plan-then-build system, but builds
a dependency graph of components and then walks it checking at each point
whether an update is needed.
% \draft{
% \begin{itemize}
% \item Previous systems:
% \begin{itemize}
% \item Early {\defsys} versions
% \item \texttt{make}
% \item \texttt{BUILD}
% \item {\mkdefsys}
% An interesting question is whether {\mkdefsys} also generated a plan before operating...
% \end{itemize}
% \item Alternative build systems:
% \begin{itemize}
% \item McDermott's chunk-based system
% \item XCVB
% \end{itemize}
% \item Systems built on top of {\ASDF}:
% \begin{itemize}
% \item Multiple software management systems:
% \begin{itemize}
% \item ASDF-INSTALL
% \item clbuild
% \end{itemize}
% \end{itemize}
}
% \end{itemize}
% Non-Lisp:
\subsection{XCVB}
% make
% OMake
% BUILD TR points out that {\make} does not support modules, so difficult to see
% the structure in makefiles. Possibly worth patching this in to earlier
% discussion.
% BUILD TR claims that \make{} is \emph{not} a plan-then-build system, but builds
% a dependency graph of components and then walks it checking at each point
% whether an update is needed.
% }
There are many related tools for other programming languages; too many to list
here. We have already discussed \make{}~\cite{Feldman79} in
Section~\ref{sec:analogy-with-make}. Omake~\cite{OMake} is an attempt to
improve on \make{}, making it more declarative. Of interest to readers of this
article are features such as automated dependency analysis, sub-project
management, and extension using a DSL (instead of relying on shell commands).
Possibly closer to \ASDF{} in flavor are integrated build systems such as
CONS~\cite{Sidebotham98} and SCONS~\cite{scons}, that aim to unify the entire
build chain. These, too, aim to overcome many of the limitations of make.
The \ant{} system for Java also attempts to go beyond \make{}, in particular in
using an XML dialect to provide more declarative system specifications.
\fixme{Add citation for \texttt{ant}; a cite to the Sun Java web site would be
fine if we can't find a better. I couldn't find a nice short article.}
\subsection{XCVB and ytools}
\label{sec:XCVB}
\rtof{I added this new introduction and tweaked the XCVB discussion a little.
Please make sure I didn't get anything wrong. Note that I \emph{added} a
couple of claims in XCVB's favor: advantage of doing it over instead of
backwards (bug) compatibility, and the fact that you don't need to worry about
image maintenance. I'm not fully sure those are correct!}
In the modern lisp world, two \ASDF{} alternatives provide an interesting
contrast. XCVB~\cite{XCVB} abandons \ASDF{}'s image maintenance task to concentrate on
doing a better job of building software systems.
On the other hand, McDermott's ytools system focuses on image maintenance,
allowing the programmer to specify dependencies for units smaller than files, up
to and including individual data structures.
XCVB, a proposed replacement for {\ASDF},
was the subject of a presentation at ILC'2009.
It is currently available through
Where {\ASDF} builds software into the current ``One True'' Lisp world
in a context-dependent way,
XCVB deterministically builds software
into multiple virtual Lisp worlds
(as many Unix processes).
On the one hand, XCVB is currently working and
has many features that {\ASDF} can't possibly be evolved to have,
such as a deterministic build model, cross-compilation,
enforcement of declared dependencies.
On the other hand, XCVB requires Common Lisp software to be adapted
XCVB is currently working and
has many features that {\ASDF} doesn't have and could not be evolved to have,
including a deterministic build model, cross-compilation,
and enforcement of declared dependencies.
On the other hand, XCVB requires {\CL} software to be adapted
to its different build specification format and
its slightly stricter build constraints,
and it doesn't currently support as many target platforms as does {\ASDF}.
So far, the advantages and inconvenients of XCVB
haven't justified a wholesale switch from {\ASDF}
by members of the Common Lisp community, or many users at all.
Development is ongoing, but from the simple one-paragraph idea
to a satisfying product, an incredible and originally unforeseen
Development of XCVB is ongoing, but from the simple one-paragraph idea
to a satisfying product, an incredible --- and originally unforeseen ---
amount of work is needed.
XCVB has to get all the details rights
in all the issues that {\ASDFii} had to face,
but also in plenty more issues,
XCVB has handle most of
the issues that we faced in {\ASDFii},
and some others as well,
from the fine semantics of UNIX signals
to distinctions between host and target system
that appear with cross-compilation.
that appear in cross-compilation.
On the other hand, XCVB has the advantages of clean slate redesign on its side,
and does not need to address the issues of image maintenance.
\fixme{ytools material here.}
......@@ -1219,7 +1250,7 @@ enable more introspection. This would be especially useful for authors of
doing this, in order to provide a stable API, especially if we were to choose to
add nested steps to \ASDF{} plans.
More modest extensions would include adding new standard operations to \ASDF{}.
More modest extensions would include adding new standard operations and components to \ASDF{}.
There have been calls to add a \lisp{doc-op}, whose function would be to build
documentation for a system. There \emph{does} exist a \lisp{test-op}, but it
has very weak semantics. System definers who implement this operation do not
......@@ -1231,6 +1262,11 @@ value.\footnote{While this might seem an obvious addition, accumulating such a
error, but one would not want a test operation to raise an error and abort on
the first failure; typically one wants a report of all passing and failing
tests.}
One component type that has been repeatedly added by system definers (and often
in a buggy way) is that of
a ``load-only'' \CL{} source file. This is a file that is to be directly loaded
and \emph{never} compiled. Previous system defining facilities, including
\mkdefsys{}~\cite{kantrowitz:91}, have included such a component type.
Perhaps the most valuable extension one could make to \ASDF{} would be to
improve its documentation. We have begun this project, but not done the
......@@ -1326,38 +1362,53 @@ work well for them does not work for others using their new classes.
\section{Conclusion}
\label{sec:conclusion}
There is nothing you can do with {\ASDFii} that one couldn't do with {\ASDFi}.
And there is nothing you can do with {\ASDFi} that you couldn't do without it.
The two above statements are trivially proven by noticing that
before you had {\ASDFi} or {\ASDFii}, you could write it, and then do
everything you can do with it.
And yet, both {\ASDFi} and {\ASDFii} do bring something useful ---
\rtof{I cut the following because as I read it, I realized that the claims are true
of any program in a Turing-complete language. I added a new sentence that I
HOPE catches your meaning.}
% There is nothing one can do with {\ASDFii} that one couldn't already do with {\ASDFi}.
% For that matter there is nothing one can do with {\ASDFi} that one couldn't do without it.
% The two above statements are trivially proven by noticing that
% before you had {\ASDFi} or {\ASDFii}, you could write it, and then do
% everything you can do with it.
Our ambitions in developing \ASDFii{} were relatively modest, and indeed the
ambitions behind \ASDF{} itself are relatively modest.
Despite this, \ASDF{} has brought something to the \CL{} community that past
system building systems failed to achieve:
%And yet, both {\ASDFi} and {\ASDFii} do bring something useful ---
the ability for developers to cooperate with each other,
using pre-negotiated conventions such that they don't each have
to pay the price of implementing it, and then again
have to pay the price of synchronizing their interface
with those of other developers.
In other words, any piece of software that isn't
the original solution of a research problem takes its value
from the economic savings it brings to people who thereby
don't have to pay the price of rewriting it,
and don't to pay the price of negotiating an interface
with other users of similar software.
\begin{itemize}
\item
Interested parties can investigate the {\ASDF} source repository.
\item There is documentation, however imperfect.
\item We'd like you to:
\begin{itemize}
\item Please incorporate {\ASDFii} into your implementations!
\item Enjoy the new features
\item Report bugs to launchpad
\item Take over maintenance
\item Help us make better documentation
\end{itemize}
\end{itemize}
using pre-negotiated conventions to share their work and build
larger \CL{} systems across the community without a shared enterprise or
top-down leadership.
% such that they don't each have
% to pay the price of implementing it, and then again
% have to pay the price of synchronizing their interface
% with those of other developers.
% In other words, any piece of software that isn't
% the original solution of a research problem takes its value
% from the economic savings it brings to people who thereby
% don't have to pay the price of rewriting it,
% and don't to pay the price of negotiating an interface
% with other users of similar software.
In revising \ASDFi{} to \ASDFii{} much of the challenge was to do so in ways
that would minimally disrupt this beneficial sharing, and ideally would further
it. We hope that the future will show that we succeeded.
We would like to conclude with an invitation to the entire \CL{} community to
enjoy \ASDFii{} and, if they are so inclined, to further contribute.
Interested parties can investigate the {\ASDF} source repository.
There is documentation, however imperfect.
We would encourage \CL{} implementers to
please incorporate {\ASDFii} into your implementations. To users we say:
\begin{itemize}
\item Enjoy the new features;
\item Report bugs to launchpad (\url{https://bugs.launchpad.net/asdf}) and
\item Help us make better documentation.
\end{itemize}
If you are really enthusiastic, take over maintenance of \ASDF{}! If you do so,
though, please be conscious of its central social role, and when changing it
``\textit{Primum non nocere}'' -- first, do no harm. We found this harder than
it first appeared.
%\appendix
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment