[asdf-devel] clearing output-translations for a "dumped" image

[Faré]

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