At 9/12/99 17:20 -0600, Arthur Flatau wrote:
>...
>A couple of simple examples might make the documentation on building
>images and delivering applications useful.

I agree, this documentation could be largely improved . BTW same thing for 
the Common Graphics documentation, especially I really would like to have 
guides on CG , I mean books : everything (hum!) is on-line.

>...
>2. It seems that I should use GENERATE-APPLICATION to build an "image"
>(or something, not sure what it is called) that I can distribute to
>the other site.  When I do this, I do get 3 files dumped, my_system,
>my_system.fasl and a libxxxx.so file.  I gather these are supposed to
>be all the files that I need to transfer to our other site to run
>there, is that correct?

Yes.
Here is a function I have used to make a runtime (ACL501 on Mswindows). 
Notice if you want to include Common Graphics in the runtime you can't use 
excl:generate-application and have to use the IDE (Build Project command).

(defun make-SI-runtime ()
   (let* ((RT-dir
           (make-pathname :directory (append *gps-directory* (list "SI-RT"))))
          (app-name (application-name))
          (destination
           (merge-pathnames (make-pathname :directory '(:relative "SI-1"))
                            RT-dir)))
     (when (probe-file destination)
       ;; like excl:delete-directory-and-files
       (delete-files destination T))
     (excl:generate-application
      app-name
      destination
      ;; like your systems file
      (list (make-pathname :defaults RT-dir :name "main" :type "lsp"))
      :restart-app-function 'gps-init-and-loop
      :restart-init-function NIL
      :runtime :standard    ; :standard , :dynamic NIL
      :include-compiler NIL ; :discard-compiler T
      :PURIFY T
      :PRESTO NIL
      :discard-local-name-info t
      :discard-source-file-info t
      :debug-on-error t ; = :debug T ?
      :exit-after-image-build T
      :allow-existing-directory T
      :splash-from-file
      (make-pathname :defaults RT-dir :name "gps" :type "bmp")
      :newspace 2000000 :oldspace 10000000
      :show-window :normal
      :include-common-graphics nil :include-devel-env nil
      :us-government nil
      :application-files (list
                          (make-pathname :defaults RT-dir
                                         :name app-name :type "ini"))
      )))


Here is an answer to an email I sent to have explanation about
the :purify argument (you can see the generated files for the
combinations of the Purify and :presto arguments):

 >I would like more information about the :purify argument in
 >generate-application . I have red the ".0 Creating and using pll files"
 >documention entry. Especially nothing is said about the costs and
 >disavantages of using pll files.
 >
 > ...
 >
 >no presto no purify :
 >   acl5016.dll 340 Kb
 >   CAMS_SI.dxl 3670 Kb
 >   CAMS_SI.exe 37 Kb
 >   CAMS_SI.ini 1 Kb
 >  Total : 4048 Kb
 >presto :
 >   acl5016.dll 340 Kb
 >   CAMS_SI.dxl 2818 Kb
 >   CAMS_SI.exe 37 Kb
 >   CAMS_SI.ini 1 Kb
 >   CAMS_SI.lib 1146 Kb
 >  Total : 4342 Kb
 >presto and purify :
 >   acl5016.dll 340 Kb
 >   CAMS_SI.dxl 1704 Kb
 >   CAMS_SI.exe 37 Kb
 >   CAMS_SI.ini 1 Kb
 >   CAMS_SI.lib 1146 Kb
 >   CAMS_SI.pll 2196 Kb
 >  Total : 5424 Kb
 >purify :
 >   acl5016.dll 340 Kb
 >   CAMS_SI.dxl 1835 Kb
 >   CAMS_SI.exe 37 Kb
 >   CAMS_SI.ini 1 Kb
 >   CAMS_SI.pll 2196 Kb
 >  Total : 4409 Kb

Probably the biggest cost to using pll files is the bookeeping
involved in having to keep track of another file as part of your
distribution or deliverable. Other than this, pll files are useful to
the extent that you make use of constant strings or codevectors. If,
for example, you are redefining lots of functions, or defining many
new functions, the codevectors in the pll will become increasingly
useless. They'll just take up space.

Also, presto and purify both serve roughly the same purpose, which is
to remove codevectors from the lisp image. As you can see from your
testing, the pll file is the same size whether or not presto is used.
By using both, you're essentially duplicating information between the
.lib and .pll files. In generating an application, you need only
choose one of these. Choosing which one depends on the needs of your
application (presto doesn't offer any saving by way of constant
strings, though that may not be particularly important for your
application).


>3. What is the deal with autoloaded functions?  Am I supposed to
>include all the modules specified in the autoload.out file when I do a
>generate-application?  If so, how?

Look at acl501\develenv.cl file

>4. Am I missing something, or is there in fact no way to specify a
>system or systems (defined with DEFSYSTEM) to generate-application,
>but I have to manually specify the files?

In my example above, the "main" file defines (systems) and loads the 
application.

Regards
Francis
--
Francis Leboutte
Algorithme, Rue de la Charrette 141, 4130 Tilff, Belgium
   <algo.be at fl>    <acm.org at leboutte>
   www.algo.be   +32-(0)4-388.3919