build-project

Arguments: project &key distribution-directory replace-if-exists exe-only autoload-warning completion-dialog (increment-build-number t)

Calls either build-lisp-image or generate-application, passing various properties of the project as arguments in order to build a standalone executable for the project. This is the programmatic equivalent of the File | Build Project Distribution and the File | Build Project Exe menu commands. This function also emulates certain other functionality of these IDE commands that is not provided by build-lisp-image or generate-application, such as embedding the project's icon file in the generated executable, and recompiling it with :runtime-system in the *features* list if the property's full-recompile-for-runtime-conditionalizations property is turned on. This function may be useful for automating the building of standalone executables for a project.

The Build tab and the Advanced tab of the Project Manager dialog allow you to specify additional arguments and other aspects of the project distribution build. There are also generic functions which can set these values, like additional-build-lisp-image-arguments.

The arguments are:

• project: The project for which to build a standalone executable or complete distribution. The project may be either the project that is currently open for editing (the value returned by current-project) or any project that has been loaded into the current IDE session by calling load-project.
• distribution-directory: The pathname or path namestring of a directory in which to place the generated distribution. Used only if exe-only is nil, in which case it must be passed. Should be either a new directory or an existing distribution directory to be replaced by passing replace-if-exists as true.
• replace-if-exists: Used only if exe-only is nil and the specified distribution-directory already exists. In this situation, if replace-if-exists is true then the distribution-directory and all of its subdirectories and the files contained in those directories are all deleted, and then the new distribution is created in a new directory at the same path. (Note that no warning is given.) If replace-if-exists is nil (the default), then an error is signaled.
• exe-only: If true, then build-lisp-image is called to create a standalone executable for the specified project. If nil (the default), then generate-application is called to create a standalone executable and place it with other files to be distributed into a new directory; this directory must be specified as the value of the distribution-directory argument.
• autoload-warning: This argument is passed straight through to either build-lisp-image or generate-application, to create an autoloads.out file to report on autoloadable functions. The IDE menu commands pass true for this argument, but nil (the default) may be more appropriate for an automated build in order to avoid an interactive modal dialog that mentions the autoloads.out file.
• completion-dialog: If true, a modal dialog with beep is presented to inform you that the process has completed. The modal dialog is a "topmost" window so that it will appear in front of other applications to which you may have shifted your attention while waiting for the build to complete. The IDE menu commands pass true for this argument, but nil (the default) may be more appropriate for an automated build in order to avoid the interactive dialog.
• increment-build-number: If true, then the build-number property of the project will be incremented by one. The default value is t. When building projects programmatically, it might be desirable to pass the value as nil to avoid modifying the project and making the IDE inclined to save it.

Automating a Project Build Using the startup.cl File

Here's a technique to automate starting up an IDE, loading a project, generating a standalone distribution, and exiting: Place code similar to the following at the top of your startup.cl file. (If this file does not exist, simply create one. startup.cl is used here because it is loaded only after the IDE has finished coming up.) This particular example will make a distribution for the IDE's form-building tutorial.

(in-package :cg-user)

(when (member "build-tutorial" (sys:command-line-arguments
                                :application t)
              :test #'string-equal)
  (let* ((project (ide:load-project
                   (merge-pathnames
                    "gui-builder-tutorial/final/interface-builder-tutorial.lpr"
                    (translate-logical-pathname "sys:"))
                   :compile nil))
         (destination "c:/tutdist/"))
    (ide:build-project project
                   :distribution-directory destination
                   :replace-if-exists t))
  (exit))

The above code will run whenever "build-tutorial" is passed as an "application argument" in the command line that is used to start up lisp. ("Application arguments" are all those following a "--" in the command line.) Such a command line, which could either be placed in a .bat batch file to be double-clicked or be used in a Windows Start Menu command, could be as simple as this ("XX" means the version indicator, e.g. "acl81"):

"c:\Program Files\aclXX\allegro.exe" -- build-tutorial

To build your own projects this way, simply replace the pathnames and command-line argument name in the sample code above, or customize it further as desired. Multiple application arguments could even be used to build the distributions for a set of projects automatically.

If an automated build fails to complete: An automated build might fail to complete, leaving the build console window on the screen, if you have turned on the "Enable Debugging of Build Errors" option for the project at some time on the Build tab of the Project Manager dialog. If this happens, you could either turn that option back off in the Project Manager, or else make the build script ensure that the option is off during the automated build by adding a line of code like the following to the build script just before it calls build-project:

Automating a Project Build Using a Make File

If you use a make facility on your system, then you could use an alternate approach that employs a makefile and one or more script files for one or more projects. This approach allows typing a briefer command line to build a particular project.

Your makefile could have a simple rule for each project, where it starts the IDE and passes the name of a script file to load for that project:

sample:
	allegro.exe +s build-sample.cl

Then the script file build-sample.cl could contain the following code that loads and builds the project.

One tricky point is that it must first wait until other processes have finished starting up the IDE. (That's not necessary when using the startup.cl approach because that file is loaded only after the IDE has finished starting up.)

(in-package :cg-user)

;;; Wait until other processes finish starting up the IDE.
(loop (when ide:*ide-is-running*
        (return))
      (sleep 0.1))

;; Load a project and generate its standalone application.
;; (You could load and build multiple projects here if desired.)
;; Using in-cg-process avoids problems if an error in this code
;; tries to display an error message in a CG window.
(in-cg-process ()
  (let* ((project-directory "c:\\allegro-projects\\sample-project\\"))
    (ide:build-project
     (ide:load-project (merge-pathnames "sample-project.lpr" project-directory))
     :distribution-directory (merge-pathnames "dist3" project-directory)
     :replace-if-exists t))
  
  ;; Exit the lisp automatically when the build is done.
  (exit))

Then in a Windows command window or Unix shell you can move to the directory that contains the makefile and simply enter make sample to build the standalone application for that project.

(setf (ide:build-flags project)
      (remove :allow-build-debug (ide:build-flags project)))

X11 and GTK on your users' machines

If you are delivering on a Mac or on Linux, make sure that your user has X11 and GTK installed. See Users of your app must have necessary software installed (such as X11 and GTK) in delivery.htm for more information.

Copyright (c) 1998-2016, Franz Inc. Oakland, CA., USA. All rights reserved.
This page has had moderate revisions compared to the 8.1 page.
Created 2016.6.21.