Next: , Previous: Compiling Programs, Up: Compiling Programs

4.1 Compilation Procedures

— procedure+: cf filename [destination]

This is the program that transforms a source-code file into native-code binary form. If destination is not given, as in 

          (cf "foo")

cf compiles the file foo.scm, producing the file foo.com (incidentally it will also produce foo.bin, foo.bci, and possibly foo.ext). If you later evaluate 

          (load "foo")

foo.com will be loaded rather than foo.scm.

If destination is given, it says where the output files should go. If this argument is a directory, they go in that directory, e.g.: 

          (cf "foo" "../bar/")

will take foo.scm and generate the file ../bar/foo.com. If destination is not a directory, it is the root name of the output: 

          (cf "foo" "bar")

takes foo.scm and generates bar.com.

About the .bci files: these files contain the debugging information that Scheme uses when you call debug to examine compiled code. When you load a .com file, Scheme remembers where it was loaded from, and when the debugger (or pp) looks at the compiled code from that file, it attempts to find the .bci file in the same directory from which the .com file was loaded. Thus it is a good idea to leave these files together.

.bci files are stored in a compressed format. The debugger has to uncompress the files when it looks at them, and on a slow machine this can take a noticeable time. The system takes steps to reduce the impact of this behavior: debugging information is cached in memory, and uncompressed versions of .bci files are kept around. The default behavior is that a temporary file is created and the .bci file is uncompressed into it. The temporary file is kept around for a while afterwards, and during that time if the uncompressed .bci file is needed the temporary file is used. Each such reference updates an `access time' that is associated with the temporary file. The garbage collector checks the access times of all such temporary files, and deletes any that have not been accessed in five minutes or more. All of the temporaries are deleted automatically when the Scheme process is killed.

Two other behaviors are available. One of them uncompresses the .bci file each time it is referenced, and the other uncompresses the .bci file and writes it back out as a .bif file. The .bif file remains after Scheme exits. The time interval and the behavior are controlled by the following variables.

— variable+: *save-uncompressed-files?*

This variable affects what happens when .bci files are uncompressed. It allows a trade-off between performance and disk space. There are three possible values:

#f
The uncompressed versions of .bci files are never saved. Each time the information is needed the .bci file is uncompressed. This option requires the minimum amount of disk space and is the slowest.
automatic
Uncompressed versions of .bci files are kept as temporary files. The temporary files are deleted when Scheme exits, or if they have not been used for a while. This is the default.
#t
The .bci files are uncompressed to permanent .bif files. These files remain on disk after Scheme exits, and are rather large—about twice the size of the corresponding .bci files. If you choose this option and you are running out of disk space you may delete the .bif files. They will be regenerated as needed.

— variable+: *uncompressed-file-lifetime*

The minimum length of time that a temporary uncompressed version of a .bci file will stay on disk after it is last used. The time is in milliseconds; the default is ‘300000’ (five minutes).

— variable+: load-debugging-info-on-demand?

If this variable is #f, then printing a compiled procedure will print the procedure's name only if the debugging information for that procedure is already loaded. Otherwise, it will force loading of the debugging information. The default value is #f.

— procedure+: sf filename [destination]

sf is the program that transforms a source-code file into binary SCode form; it is used on machines that do not support native-code compilation. It performs numerous optimizations that can make your programs run considerably faster than unoptimized interpreted code. Also, the binary files that it generates load very quickly compared to source-code files.

The simplest way to use sf is just to say: 

          (sf filename)

This will cause your file to be transformed, and the resulting binary file to be written out with the same name, but with pathname type "bin". If you do not specify a pathname type on the input file, "scm" is assumed.

Like load, the first argument to sf may be a list of filenames rather than a single filename.

sf takes an optional second argument, which is the filename of the output file. If this argument is a directory, then the output file has its normal name but is put in that directory instead.