Next: Controlling source file character encoding, Previous: Miscellaneous additional functionality, Up: Miscellaneous additional functionality [Contents][Index]
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).