Re: [asdf-devel] fare-utils build failure
Cc'ng asdf-devel. On Wed, Jan 16, 2013 at 9:30 AM, Zach Beane <xach@xach.com> wrote:
Faré <fahree@gmail.com> writes:
How do I get asdf-driver?
It's currently part of the asdf git tree. Should I make it separate? I think you can already include asdf-driver.asd without including asdf.
What is the relationship between asdf-driver and asdf? What is a driver?
asdf uses asdf-driver. asdf-driver is currently distributed as part of the asdf source tree, but if that is an issue, there is no barrier to splitting it apart. For bootstrap purposes, the source code of asdf-driver is transcluded into asdf.lisp as a prelude to asdf, so asdf can rely on it. asdf-driver is a general purpose portability and runtime management library. It provides various abstraction layers for packages, pathnames, command-line arguments, compilation, condition-muffling, run-program, image dump and restore with hooks, basic I/O, etc. Basically, it's all the portability work I did over the last few years as part of asdf and xcvb, so as to be able to run user code unchanged (above the abstraction layer) on all supported lisp implementations. When rpgoldman convinced me that a portable, usable run-program should be part of asdf, whereas the legacy run-shell-command is an unusable unmaintainable unfixable crock, I decided to pull in the implementation from xcvb-driver. At the same time, drewc convinced me that having plenty of smaller files, with one package per file, was a good idea. I have been haunted for a few years for having failed janderson when he proposed to split asdf in parts; yet now asdf.lisp is much bigger than it was then, and at the same, having integrated bundle operations and figured out the dependency mess means it's easier and safer to write a general purpose source-concatenation operation. Finally you (Xach) convinced me that ASDF itself should not be a utility library, but only a build system; at the same time I really need the portability library, for XCVB as well as for ASDF and for any portable CL code I write. To top it all, after having completely reimplemented ASDF several times, I have started feeling much more comfortable with taking it apart and reassembling it in better ways. So there. I split ASDF in parts, and the part that's not specific to the system definition facility has been separated into asdf-driver. On most implementations, you can upgrade asdf-driver on top of an old ASDF -- though I admit I haven't yet added this situation to my automated testing regime. (The outlier as usual is CLISP, which is very funky to upgrade, and I don't know how to do things short of deleting the ASDF package when there's an incompatibility, which isn't conducive to upgrading ASDF-DRIVER far beyond ASDF; but I have ideas on how to make things a little bit more usable.) —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org If I go through life free and rich, I shall not cry because my neighbour, equally free, is richer. Liberty will ultimately make all men rich; it will not make all men equally rich. Authority may (and may not) make all men equally rich in purse; it certainly will make them equally poor in all that makes life best worth living. — Benjamin Tucker
Faré <fahree@gmail.com> writes:
Cc'ng asdf-devel.
On Wed, Jan 16, 2013 at 9:30 AM, Zach Beane <xach@xach.com> wrote:
Faré <fahree@gmail.com> writes:
How do I get asdf-driver?
It's currently part of the asdf git tree. Should I make it separate? I think you can already include asdf-driver.asd without including asdf.
What is the relationship between asdf-driver and asdf? What is a driver?
asdf uses asdf-driver. asdf-driver is currently distributed as part of the asdf source tree, but if that is an issue, there is no barrier to splitting it apart.
For bootstrap purposes, the source code of asdf-driver is transcluded into asdf.lisp as a prelude to asdf, so asdf can rely on it.
asdf-driver is a general purpose portability and runtime management library. It provides various abstraction layers for packages, pathnames, command-line arguments, compilation, condition-muffling, run-program, image dump and restore with hooks, basic I/O, etc.
For nearly all other libraries, there is a repo or .tgz file I can download to package it up for Quicklisp. It would be nice if that was the case for asdf-driver, too. Zach
On Wed, Jan 16, 2013 at 10:23 AM, Zach Beane <xach@xach.com> wrote:
For nearly all other libraries, there is a repo or .tgz file I can download to package it up for Quicklisp. It would be nice if that was the case for asdf-driver, too.
Sure. Which format do you prefer? If I remember correctly, you will want a directory asdf-driver-2.26.100/ containing the code. PS: I'm declaring asdf-utils and xcvb-utils obsolete and will be removing them. I've also stripped xcvb-driver of all its portability layer and will redirect my packages (such as inferior-shell) to use asdf-driver instead. I was sorely missing the pathname portability in xcvb-driver, and it has now been cleaned up and documented in asdf-driver. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Any sufficiently advanced bug is indistinguishable from a feature. — Rich Kulawiec
Faré <fahree@gmail.com> writes:
On Wed, Jan 16, 2013 at 10:23 AM, Zach Beane <xach@xach.com> wrote:
For nearly all other libraries, there is a repo or .tgz file I can download to package it up for Quicklisp. It would be nice if that was the case for asdf-driver, too.
Sure. Which format do you prefer? If I remember correctly, you will want a directory asdf-driver-2.26.100/ containing the code.
Either format is fine. Sometimes a tarball implies a level of release engineering.
PS: I'm declaring asdf-utils and xcvb-utils obsolete and will be removing them. I've also stripped xcvb-driver of all its portability layer and will redirect my packages (such as inferior-shell) to use asdf-driver instead. I was sorely missing the pathname portability in xcvb-driver, and it has now been cleaned up and documented in asdf-driver.
A number of my private projects depend on asdf-utils. If you do not wish to maintain it, please let someone else do it. Zach
On Wed, Jan 16, 2013 at 10:32 AM, Zach Beane <xach@xach.com> wrote:
Faré <fahree@gmail.com> writes:
Sure. Which format do you prefer? If I remember correctly, you will want a directory asdf-driver-2.26.100/ containing the code.
Either format is fine. Sometimes a tarball implies a level of release engineering.
That begs the question: how should asdf be distributed? As asdf.lisp only? As a tarball or git checkout with everything? As a tarball with only the asdf-specific source files, to be combined with asdf-driver code into asdf.lisp? Some or all of the above? As for me, I'll keep using the git checkout, but I suppose you might have ideas as to what you prefer for quicklisp.
PS: I'm declaring asdf-utils and xcvb-utils obsolete and will be removing them. I've also stripped xcvb-driver of all its portability layer and will redirect my packages (such as inferior-shell) to use asdf-driver instead. I was sorely missing the pathname portability in xcvb-driver, and it has now been cleaned up and documented in asdf-driver.
A number of my private projects depend on asdf-utils. If you do not wish to maintain it, please let someone else do it.
Then I am inclined to make asdf-utils an alias for asdf-driver, and add the nickname :asdf-utils to :asdf/driver. All the functions in asdf-utils are present in asdf-driver (Well, I admit I refactored away a few that couldn't be found used on quicklisp, but they hopefully won't be missed; for instance if you rely on the old name coerce-pathname instead of the more general parse-unix-namestring, buzz me.) And yes, I am willing to maintain it for the time being. It is also still time to wholly rename asdf-driver into asdf-utils, if you think that is preferable: you're the only user I've heard of. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The urge to save humanity is almost always a false front for the urge to rule. — H. L. Mencken
Faré <fahree@gmail.com> writes:
On Wed, Jan 16, 2013 at 10:32 AM, Zach Beane <xach@xach.com> wrote:
Faré <fahree@gmail.com> writes:
Sure. Which format do you prefer? If I remember correctly, you will want a directory asdf-driver-2.26.100/ containing the code.
Either format is fine. Sometimes a tarball implies a level of release engineering.
That begs the question: how should asdf be distributed?
Does it? I thought we were talking about asdf-driver.
As asdf.lisp only?
Yes. As it always has been. Zach
Faré <fahree@gmail.com> writes:
A number of my private projects depend on asdf-utils. If you do not wish to maintain it, please let someone else do it.
Then I am inclined to make asdf-utils an alias for asdf-driver, and add the nickname :asdf-utils to :asdf/driver.
When I try to build XCVB now, I get this: BORK: ASDF-UTILS is a nickname for the package ASDF/DRIVER I'm not sure if it's due to XCVB directly or a supporting library. Same thing happens for exscribe, inferior-shell, coleslaw, and others. Zach
participants (2)
-
Faré -
Zach Beane