1.4 API for Making Bytecode🔗ℹ

• the file is expected to contain a module (i.e., the second argument to the handler is a symbol);

• the value of each of (current-eval), (current-load), and (namespace-module-registry (current-namespace)) is the same as when make-compilation-manager-load/use-compiled-handler was called;

• the value of use-compiled-file-paths contains the first path that was present when make-compilation-manager-load/use-compiled-handler was called;

• the value of current-load/use-compiled is the result of this procedure; and

• one of the following holds:

  • the source file is newer than the ".zo" file in the first sub-directory listed in use-compiled-file-paths (at the time that make-compilation-manager-load/use-compiled-handler was called), and either no ".dep" file exists or it records a source-file SHA-1 hash that differs from the current version and source-file SHA-1 hash;

  • no ".dep" file exists next to the ".zo" file;

  • the version recorded in the ".dep" file does not match the result of (version);

  • the target machine recorded in the ".dep" file does not match the result of (current-compile-target-machine);

  • the source hash recorded in the ".dep" file does not match the current source hash;

  • one of the files listed in the ".dep" file has a ".zo" timestamp newer than the target ".zo" and use-compiled-file-check is set to 'modify-seconds;

  • the combined hashes of the dependencies recorded in the ".dep" file does not match the combined hash recorded in the ".dep" file.

If SHA-1 hashes override a timestamp-based decision to recompile the file, then the target ".zo" file’s timestamp is updated to the current time, unless the use-compiled-file-check parameter is not set to 'modify-seconds.

After the handler procedure compiles a ".zo" file, it creates a corresponding ".dep" file that lists the current version and the identification of every file that is directly required by the module in the compiled file. Additional dependencies can be installed during compilation via compiler/cm-accomplice. The ".dep" file also records the SHA-1 hash of the module’s source, and it records a combined SHA-1 hash of all of the dependencies that includes their recursive dependencies. If a bytecode file is generated by recompiling a bytecode file that was formerly compiled as machine-independent, then the ".dep" file also records the SHA-1 hash of the machine-independent form, since the recompiled module’s behavior should be exactly the same.

The special combination of (cross-installation?) or (current-multi-compile-any) as #t, (current-compile-target-machine) as #f, and (current-compiled-file-roots) having two or more elements triggers a special compilation mode. Bytecode specific to the running Racket is written to the directory determined by the first element of (current-compiled-file-roots). Bytecode specific to either the cross-compilation target for (cross-installation?) or machine-independent format if (current-multi-compile-any) is written to the directory determined by the second element of (current-compiled-file-roots). By configuring (current-compiled-file-roots) so that the first element is outside a build tree and the second element is inside the build tree, cross-compilation can create a build tree suitable for the target machine while building and loading bytecode (for macro expansion, etc.) that is usable on the current machine. This mode works correctly for a build directory that starts with only source code and machine-independent bytecode.

The handler caches timestamps when it checks ".dep" files, and the cache is maintained across calls to the same handler. The cache is not consulted to compare the immediate source file to its ".zo" file, which means that the caching behavior is consistent with the caching of the default module name resolver (see current-module-name-resolver).

If use-compiled-file-paths contains an empty list when make-compilation-manager-load/use-compiled-handler is called, then an exn:fail:contract exception is raised.

If the delete-zos-when-rkt-file-does-not-exist? argument is a true value, then the returned handler will delete ".zo" files when there is no corresponding original source file.

If the security-guard argument is supplied, it is used when creating ".zo" files, ".dep" files, and "compiled/" directories, and when it adjusts the timestamps for existing files. If it is #f, then the security guard in the current-security-guard when the files are created is used (not the security guard at the point make-compilation-manager-load/use-compiled-handler is called).

The continuation of the compilation of a module is marked with a managed-compiled-context-key and the module’s source path.

Do not install the result of make-compilation-manager-load/use-compiled-handler when the current namespace contains already-loaded versions of modules that may need to be recompiled—unless the already-loaded modules are never referenced by not-yet-loaded modules. References to already-loaded modules may produce compiled files with inconsistent timestamps and/or ".dep" files with incorrect information.

The handler logs messages to the topic 'compiler/cm at the level 'info. These messages are instances of a compile-event prefab structure:

Changed in version 6.1.1.8 of package base: Added identification of the compilation context via managed-compiled-context-key.
Changed in version 6.6.0.3: added check on a source’s SHA1 hash to complement the timestamp check, where the latter can be disabled via use-compile-file-check.

Compilation is triggered by loading a module into the current namespace, so if a module that is a dependency of file has already been loaded into the current namespace, then that module will not necessarily be (re-)compiled. The handler used to trigger compilation is created with make-compilation-manager-load/use-compiled-handler, so all the rules and constraints there apply.

If file is compiled from source, then read-src-syntax is used in the same way as read-syntax to read the source module. The normal read-syntax is used for any required files, however.

If security-guard is not #f, then the provided security guard is used when creating the "compiled/" directories, ".dep" and ".zo" files, and when it adjusts the timestamps of existing files. If it is #f, then the security guard in the current-security-guard when the files are created is used (not the security guard at the point managed-compile-zo is called).

While compiling file, the error-display-handler parameter is set to (make-compilation-context-error-display-handler (error-display-handler)), so that errors from uncaught exceptions will report the compilation context.

Changed in version 6.1.1.8 of package base: Added error-display-handler configuration.

Added in version 6.1.1.8 of package base.

Added in version 6.1.1.8 of package base.

A handler to support compilation is created with make-compilation-manager-load/use-compiled-handler each time the result of make-caching-managed-compile-zo is called, so the current namespace and other parameter values are relevant at that time, not when make-caching-managed-compile-zo is called.

The default value of the parameter logs the argument, along with current-inexact-milliseconds, to a logger named 'compiler/cm at the 'debug level.

Note that this parameter is not used by current-load/use-compiled. So if the parameter causes ".zo" files to be placed in different directories, then the correct ".zo" file must still be communicated via use-compiled-file-paths, and one way to do that is to override current-load/use-compiled to delete ".zo" files that would cause the wrong one to be chosen right before they are loaded.

Added in version 6.4.0.14 of package base.

This function is intended for use with manager-skip-file-handler.

When proc is #f (the default), no checking for parallel compilation is done (and thus multiple threads or places running compilations via make-compilation-manager-load/use-compiled-handler will potentially corrupt each other’s ".zo" files).

When proc is a function, its first argument is a command 'lock pr 'unlock, which indicates whether the caller wants to lock or unlock a target zo-path, and the second argument is the target zo-path (expressed as a byte string).

When proc returns #t for a 'lock command, the current builder has obtained the lock for zo-path. Once compilation of zo-path is complete, the builder process must release the lock by calling proc 'unlock with the exact same zo-path.

When proc returns #f for a 'lock command, another parallel builder obtained the lock first and has already compiled the target. The parallel builder should continue without compiling zo-path. (In this case, make-compilation-manager-load/use-compiled-handler’s result will not call proc with 'unlock.)

This communication protocol implementation is not kill-safe when cust is #f. Making the protocol kill-safe requires a sufficiently powerful custodian (i.e., one that is not subject to termination unless all of the participants in the compilation are also terminated) supplied as cust. The given custodian is used to create a thread that monitors the threads that are perform the compilation. If one of the threads is terminated, the presence of the custodian lets another one continue. (The custodian is also used to create a thread that manages a thread-safe table.)

Just checking for thread termination is not always sufficient to release a lock, because a thread created with thread/suspend-to-kill is merely suspending by removing its ability to run. The current-shutdown-evt argument returns an synchronizable event that the monitor thread waits on at the same time as it waits for a thread to terminate. If the event becomes ready, then the monitor releases a lock the same as if the thread was terminated. For example, current-shutdown-evt might return a custodian box to detect a custodian shutdown.

Changed in version 8.1.0.7 of package base: Added the current-shutdown-evt argument.

Added in version 6.3 of package base.

Added in version 8.1.0.2 of package base.