On Wed, Feb 20, 2013 at 12:46 AM, Dave Cooper david.cooper@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 •Reflection&Cybernethics• 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"