On Wed, Feb 20, 2013 at 12:46 AM, Dave Cooper david.coo...@genworks.com wrote:
Holy Cow I started looking through ADSF3 (asdf 2.29) and it is starting to
do everything under the sun!
Well, not *everything*, just everything needed to portably bootstrap
the building of Common Lisp code.
The new functionality like the ASDF/DRIVER compatibility layer, dumping
images, and concatenated fasls look really useful and have potential to
simplify things on our end a lot.
That's the whole point of it.
So ASDF/DRIVER has superseded asdf-utils, right?
Yes it has. There is a package nickname that says so,
and asdf-utils is now an otherwise empty system that depends on asdf/driver.
The functions in 10.3 Miscellaneous Functions of the documentation
are the main functions now in ASDF/DRIVER? Or I suppose there are a lot more
now -- and the main documentation for the moment are in the source code
(understandable).
The manual has been minimally updated. Writing then debugging ASDF3
took so much energy that I didn't have much left for writing the manual,
especially since things were moving fast while I made many passes
to refactor the API until it was in a satisfying shape.
For dumping of images, I see for Allegro CL this maps to excl:dumplisp with
only a couple of keyword arguments, which is fine for basic dumping of
images when there's not a lot of need of fine control. As you may or may not
know, Allegro CL has a couple other ways of making executable images:
excl:generate-application and excl:build-lisp-image. For our distributions
we sometimes have to call these functions instead of excl:dumplisp. When
the ASDF3 dust has settled a bit and I understand the workings of ASDF3 a
bit better, I hope I (or somebody -- maybe somebody from Franz?) will be
able to extend the image-dumping support in ASDF to handle these Allegro CL
functions as well. But, these functions take many (maybe dozens) of keyword
arguments, so maybe it starts to go beyond what a reasonable portability
layer like what ASDF is trying to achieve should be trying to provide...
(actually excl:dumplisp takes many of the same keyword arguments as well...
so I suppose the answer is that if one needs that find level of control, one
had better go ahead and directly call the native version).
Yes, for the moment, you'll have to go native if you need the support.
Nonetheless I still recommend you use ASDF3 and respect its hooks
as you dump the image:
(setf *image-dumped-p* (if executable :executable t))
(standard-eval-thunk *image-postlude*)
(call-image-dump-hook)
Then use restore-image as your restart function.
If you contribute support for all these options and more to asdf/image,
I would be grateful.
Anyway for the time being, if I am using ASDF3 with Allegro CL, and want to
use excl:generate-application or excl:build-lisp-image, in order to clear
the configuration, is the
(asdf:clear-configuration)
still going to work as in ASDF2?
Yes, it will;
but still I recommend you use ASDF3 and its hooks instead (see above).
—♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org
Throughout history, poverty is the normal condition of man. Advances which
permit this norm to be exceeded — here and there, now and then — are the
work of an extremely small minority, frequently despised, often condemned,
and almost always opposed by all right-thinking people. Whenever this tiny
minority is kept from creating, or (as sometimes happens) is driven out of
a society, the people then slip back into abject poverty.
This is known as bad luck.
— Robert Heinlein, Time Enough For Love
___
asdf-devel mailing list
asdf-devel@common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
