Hallo there!
I want to study portable cl build/install related programs/utilities
thoroughly. For now I am aware of the following ones:
Build:
- defsystem
- asdf (with some additions and extensions many of which are not
mature)
Install
- asdf-install
- clbuild
- common-lisp-controller
- cl-librarian
There are also related topics as:
- autoloading (seen smth in cllib)
- package system convinience libraries such as conduit packages or
hierarchical packages
- unit testing suites
Is there some overview of the question for newbies on the net?
Thanks.
budden <···········@mail.ru> writes:
> Hallo there!
> I want to study portable cl build/install related programs/utilities
> thoroughly. For now I am aware of the following ones:
>
> Build:
> - defsystem
> - asdf (with some additions and extensions many of which are not
> mature)
>
> Install
> - asdf-install
> - clbuild
> - common-lisp-controller
> - cl-librarian
>
> There are also related topics as:
> - autoloading (seen smth in cllib)
> - package system convinience libraries such as conduit packages or
> hierarchical packages
> - unit testing suites
>
> Is there some overview of the question for newbies on the net?
There's also the recent mudballs.
And for inspiration, you may have a look at the various linux
distributions each with their own package management system (rpm,
emerge, apt-get, etc).
--
__Pascal Bourguignon__
* budden Wrote on Fri, 19 Dec 2008 02:22:43 -0800 (PST):
| I want to study portable cl build/install related programs/utilities
| thoroughly. For now I am aware of the following ones:
Apart from those two mentioned, from the top of my head (without
consulting google):
- Joachim H. Laubsch's defsystem is in the cmu-ai repo from around 92.
- Peter Bengtson wrote YADS (Yet another defsystem facility) around 97.
- Ora Lassila wrote a defsystem included with wilbur-rdf.
Lots of packages also come with system definition and configuration
facilities, like powerloom, ytools with lsy etc.
Commercial lisp implementations (lispm, franz lw) each come with their
own defsystems.
Once you read KMP's paper you can write your own defsystem in an
afternoon or weekend.
[It may be easier to count grains of sand in the beach than the number
of system definition facilities out there. Or something. Did you have
a specific reason for this study?]
--
Madhu
On Dec 19, 12:09 pm, Madhu <·······@meer.net> wrote:
> * budden Wrote on Fri, 19 Dec 2008 02:22:43 -0800 (PST):
>
> | I want to study portable cl build/install related programs/utilities
> | thoroughly. For now I am aware of the following ones:
>
> Apart from those two mentioned, from the top of my head (without
> consulting google):
>
> - Joachim H. Laubsch's defsystem is in the cmu-ai repo from around 92.
> - Peter Bengtson wrote YADS (Yet another defsystem facility) around 97.
> - Ora Lassila wrote a defsystem included with wilbur-rdf.
>
> Lots of packages also come with system definition and configuration
> facilities, like powerloom, ytools with lsy etc.
>
> Commercial lisp implementations (lispm, franz lw) each come with their
> own defsystems.
>
> Once you read KMP's paper you can write your own defsystem in an
> afternoon or weekend.
>
> [It may be easier to count grains of sand in the beach than the number
> of system definition facilities out there. Or something. Did you have
> a specific reason for this study?]
>
> --
> Madhu
For the record, I recently found this paper:
ftp://publications.ai.mit.edu/ai-publications/pdf/AITR-874.pdf
BUILD: A tool for maintaining consistency in modular systems
by Richard Elliot Robbins, 1985
On Dec 19, 2:38 pm, ·······@corporate-world.lisp.de" <······@corporate-
world.lisp.de> wrote:
> On Dec 19, 12:09 pm, Madhu <·······@meer.net> wrote:
>
>
>
> > * budden Wrote on Fri, 19 Dec 2008 02:22:43 -0800 (PST):
>
> > | I want to study portable cl build/install related programs/utilities
> > | thoroughly. For now I am aware of the following ones:
>
> > Apart from those two mentioned, from the top of my head (without
> > consulting google):
>
> > - Joachim H. Laubsch's defsystem is in the cmu-ai repo from around 92.
> > - Peter Bengtson wrote YADS (Yet another defsystem facility) around 97.
> > - Ora Lassila wrote a defsystem included with wilbur-rdf.
>
> > Lots of packages also come with system definition and configuration
> > facilities, like powerloom, ytools with lsy etc.
>
> > Commercial lisp implementations (lispm, franz lw) each come with their
> > own defsystems.
>
> > Once you read KMP's paper you can write your own defsystem in an
> > afternoon or weekend.
>
> > [It may be easier to count grains of sand in the beach than the number
> > of system definition facilities out there. Or something. Did you have
> > a specific reason for this study?]
>
> > --
> > Madhu
>
> For the record, I recently found this paper:
>
> ftp://publications.ai.mit.edu/ai-publications/pdf/AITR-874.pdf
>
> BUILD: A tool for maintaining consistency in modular systems
> by Richard Elliot Robbins, 1985
Here is also Kent Pitman on a failed ANSI CL proposal:
http://www.nhplace.com/kent/CL/Issues/defsystem.html
Madhu <·······@meer.net> writes:
> [It may be easier to count grains of sand in the beach than the number
> of system definition facilities out there. Or something. Did you have
> a specific reason for this study?]
I'd bet it's in preparation of writting yet another system definition facility!
--
__Pascal Bourguignon__
> I'd bet it's in preparation of writting yet another system definition facility!
Mmm, what is your bet? You lose! It is an attempt to avoid writing
one. For now, I see asdf and asdf-install seem to be most popular.
Clbuild is live and asdf-install is likely to be dying. But no general
satisfactory solution.
> Did you have a specific reason for this study?
Yes. I want to use software written by others. And I want that every
lisp newbie was able to navigate his way between the defsystems. For
now, I see no satisfactory defsystem.
Satisfactory defsystem should cover the following questions:
- automated installation from manageable list of locations (like /etc/
apt/sources.list)
- check of installation correctness
- support of the "worlds" (like version series in debian: etch/
lenny/... and apt-get dist-upgrade)
- introspection (like dpkg -S) to find:
-- where the system is located
-- what is its version
-- what are the dependencies
-- to what system given file/package/symbol belongs
-- find system by keywords in its description
- ability to add new library with a well described standard procedure
(and people who support it)
- ability to convert from heritage defsystems or integrate them
smoothly
> Once you read KMP's paper you can write your own defsystem in an afternoon or weekend.
Is that a reason for doing that? For what? For satisfying NIH syndrom?
I've got no one. What I like to do is to install libraries easily. In
fact, I've already done two defsystems for SQL server side
(views,sp's,grants), one of them was simply a makefile, second was
lisp-based. Making crappy defsystem takes an afternoon. Making a good
one didn't feet in a week, finally I ran out of time and didn't finish
it at all.
How many time it would take in production to learn new defsystem every
time I need new library? E.g. debian has (mainly) two ways of
installing:
1. use apt (easy)
2. download binaries/build from sources (more powerful)
I think that's enough.
If there are many defsystems, I'd like to see some methodics to
coercing them to some common solution. E.g. "my-super-defsystem-to-
asdf".
It looks like clbuild/asdf can be patched to satisfy all the
requirements, but maybe there already is a ready better solution.
Hi Madhu, list
Thanks everyone for keywords, go on. I'd like some opinions/
impressions, too.
I took a look at defsystem proposal, it looks useful.
Why do I dislike Mudballs? Here is Mudballs rationale (from its home
page).
* Operations on components don't happen in the context of a call to
the parent system.
* Pervasive use of soft links makes Windows users second class
citizens.
* Inability to have multiple versions of the same system defined.
First consideration is rather serious. But parent system is
accessible through asdf metadata, so we can know something about
context of operation anyway. It is necessary to know what exactly did
Mudballs authors wanted from the context.
Second is a small issue which can be solved easily due to
extensibility of asdf architecture. I solved it (for lispworks) in a
several hours (if I was less stupid and more lucky, I could made it in
a hour, but I spent many time writing a clone of already existing
readlink.exe program). http://groups.google.com/group/comp.lang.lisp/browse_thread/thread/2fd0eb8bf961c08b#
I still didn't try to address third issue, but we have
asdf::*central-registry* and asdf::*system-definition-search-
functions*. Certanly, this is more than enough to make multi-version
world possible. Just the most stupid thing:
write in initialization file:
(require :asdf)
(push #+lib1.1 (list "/usr/local/lib/lisp/1.1/") #+lib1.2 (list "/usr/
local/lib/lisp/1.2/")
asdf::*central-registry*)
This switches the whole universe. There is also already an extension
which allows to switch universes.
To work per-library, one can have an alist of versions and write one's
own search function which
reads that alist and finds an appropriate version by its folder name,
e.g.
(push '(:foo . 1.4) *asfd-version-alist*)
and function would find cl-foo-1.4, but not cl-foo-1.5
So, most of the problems in the rationale of Mudballs are solved
easily. Instead of solving them by adding compatible extensions to
asdf, Mudballs author (I could not find his name on the site)
preferred to create new tool with incompatible syntax and provided
even no tool for automatic conversion of asdf systems. If he would
promote Mudballs rather actively, this will, on my opinion, lead to
further fragmenting of lisp society which is not that strong.
I didn't thought about installation yet, but clbuild looks like
almost ok. Its problem is that it is developed for unstable
development and does not address notion of stable
"distributions" (like apt does). However, it can be solved easily too.
If someone wants to provide a "distribution", he can just publish it
as repo. Users will need only take projects and dependencies files and
then do sh clbuild update ... (their projects) The second clbuild's
problem (for me) is that tarball distributed libraries are not
included. There is rationale for that, and it is respectable.
Meanwhile, the problem of getting list of library locations persist so
we have some gap in functionality required.
Then, asdf syntax is acceptable, it is rather flexible, and asdf
itself is extensible in several directions. E.g. if we don't like asdf
compilation vs loading behavior, and we don't like :serial t, we can
define our own 'asdf::smart-load-op which acts as we want. Syntax can
also be extended using #+feature mechanism. E.g.
(defsystem :foo-library
#+asdf+ (:package "FOO" "packages.lisp")
(:depends-on ...))
If some user do not have an extended asdf, he would still be able to
load.
So my current intension is in fact to improve asdf by unleashing its
hidden (not hidden, in fact, but very transparent and even documented)
potential.
Did anyone worked with common-lisp-controller? As far as I can
judje, it is used in apt to install lisp libraries.