contrib/Support-dumping-compressed-executables-in-dump-macro.patch

   1 From 7ec1ca5e29c1337355186129da7e9f2778fdf9d1 Mon Sep 17 00:00:00 2001
   2 From: Jan Moringen <jmoringe@techfak.uni-bielefeld.de>
   3 Date: Fri, 13 Jul 2012 12:43:29 +0200
   4 Subject: [PATCH] Support dumping compressed executables in dump macro
   5
   6 The interface is rather generic wict safe behaviors for implementations
   7 which do not support compression.
   8
   9 Currently, compression is only supported in SBCL.
  10 ---
  11  src/util.lisp |   51 +++++++++++++++++++++++++++++++++++++++++++++++++--
  12  1 files changed, 49 insertions(+), 2 deletions(-)
  13
  14 diff --git a/src/util.lisp b/src/util.lisp
  15 index 911caf2..9c82637 100644
  16 --- a/src/util.lisp
  17 +++ b/src/util.lisp
  18 @@ -420,9 +420,29 @@ public class ~A
  19  }~%"
  20    "Main class template for ABCL.")
  21
  22 -(defmacro dump (name function)
  23 +(defmacro dump (name function
  24 +               &key
  25 +               compression
  26 +               (if-compression-not-supported :warn))
  27    "Dump a standalone executable named NAME starting with FUNCTION.
  28
  29 +COMPRESSION controls whether and to which extend the produced
  30 +executable should be compressed. Valid values are:
  31 +
  32 +  nil      Do not compress the executable.
  33 +  :DEFAULT Use default compression.
  34 +  :FASTEST Use fastest compression, possibly increasing executable size.
  35 +  :BEST    Use most compact compression, possibly
  36 +           increasing (de)compression time.
  37 +
  38 +IF-COMPRESSION specifies the behavior in case compression is
  39 +requested, but not available in an implementation. Valid values are:
  40 +
  41 +  :CONTINUE Continue without compressing the executable.
  42 +  :WARN     Continue without compressing the executable and signal a
  43 +            warning.
  44 +  :ERROR    Signal an error.
  45 +
  46  Since executable dumping is not available in all supported implementations,
  47  this function behaves differently in some cases, as described below.
  48
  49 @@ -436,12 +456,39 @@ this function behaves differently in some cases, as described below.
  50    ;; #### PORTME.
  51    #+ecl     (declare (ignore name))
  52    #+allegro (declare (ignore function))
  53 +
  54 +  (check-type compression (member nil :default :fastest :best)
  55 +             "one of nil, :DEFAULT, :FASTEST or :BEST")
  56 +
  57 +  (check-type if-compression-not-supported
  58 +             (member :continue :warn :error)
  59 +             "one of :CONTINUE, :WARN or :ERROR")
  60 +
  61 +  #+(or (and sbcl (not sb-core-compression))
  62 +       (not sbcl))
  63 +  (when compression
  64 +    (ecase if-compression-not-supported
  65 +      (:continue)
  66 +      (:warn
  67 +       (warn "~@<Dumping compressed executables is not supported in this implementation.~@:>"))
  68 +      (:error
  69 +       (cerror "~@<Dump an uncompressed executable instead.~@:>"
  70 +              "~@<Dumping compressed executables is not supported in this implementation.~@:>"))))
  71 +
  72 +  ;; #### PORTME.
  73    #+sbcl    `(progn
  74                (setq *executablep* t) ; not used but here for correctness
  75                (sb-ext:save-lisp-and-die ,name
  76                  :toplevel #',function
  77                  :executable t
  78 -                :save-runtime-options t))
  79 +                :save-runtime-options t
  80 +                #+sb-core-compression
  81 +                :compression
  82 +                #+sb-core-compression
  83 +                ,(case compression
  84 +                   (:default -1)
  85 +                   (:fastest 0)
  86 +                   (:best 9))))
  87    #+cmu     `(progn
  88                (setq *executablep* t)
  89                (ext:save-lisp ,name
  90 --
  91 1.7.0.4
  92
  93
  94   Hi Jan!
  95
  96 Thank you for the patch. What worries me a little is that DUMP was never
  97 really intended to be a universal wrapper around implementation-specific
  98 dumping facilities. Your patch is sort of opening the door to this (who
  99 knows how many vendor options I will need to support in the future?) and
 100 I fear that it may become a Rube Goldberg machine.
 101
 102 I would rather be enclined to just change it to
 103
 104 DUMP (NAME FUNCTION &REST <or &KEY> ARGS)
 105
 106 so that ARGS is blindly passed to the underlying implementation. I still
 107 haven't made up my mind completely...