11.1 Controlling file compilation

When declaring a component (system, module, file), you can specify a keyword argument :around-compile function. If left unspecified (and therefore unbound), the value will be inherited from the parent component if any, or with a default of nil if no value is specified in any transitive parent.

The argument must be either nil, an fbound symbol, a lambda-expression (e.g. (lambda (thunk) ...(funcall thunk ...) ...)) a function object (e.g. using #.#' but that’s discouraged because it prevents the introspection done by e.g. asdf-dependency-grovel), or a string that when read yields a symbol or a lambda-expression. nil means the normal compile-file function will be called. A non-nil value designates a function of one argument that will be called with a function that will invoke compile-file* with various arguments; the around-compile hook may supply additional keyword arguments to pass to that call to compile-file*.

One notable argument that is heeded by compile-file* is :compile-check, a function called when the compilation was otherwise a success, with the same arguments as compile-file; the function shall return true if the compilation and its resulting compiled file respected all system-specific invariants, and false (nil) if it broke any of those invariants; it may issue warnings or errors before it returns nil. (NB: The ability to pass such extra flags is only available starting with ASDF 2.22.3.) This feature is notably exercised by asdf-finalizers.

By using a string, you may reference a function, symbol and/or package that will only be created later during the build, but isn’t yet present at the time the defsystem form is evaluated. However, if your entire system is using such a hook, you may have to explicitly override the hook with nil for all the modules and files that are compiled before the hook is defined.

Using this hook, you may achieve such effects as: locally renaming packages, binding *readtables* and other syntax-controlling variables, handling warnings and other conditions, proclaiming consistent optimization settings, saving code coverage information, maintaining meta-data about compilation timings, setting gensym counters and PRNG seeds and other sources of non-determinism, overriding the source-location and/or timestamping systems, checking that some compile-time side-effects were properly balanced, etc.

Note that there is no around-load hook. This is on purpose. Some implementations such as ECL, GCL or MKCL link object files, which allows for no such hook. Other implementations allow for concatenating FASL files, which doesn’t allow for such a hook either. We aim to discourage something that’s not portable, and has some dubious impact on performance and semantics even when it is possible. Things you might want to do with an around-load hook are better done around-compile, though it may at times require some creativity (see e.g. the package-renaming system).