Changes to fallback handlers for require-module

Entries on *fallback-module-loaders* now get all the explicit arguments passed to require-module itself, which means you can control things like verbosity. The value of the fallback argument is still given just the module, so it can be concise.

This is not entirely compatible with older versions, but is an improvement.

Read version from file

This should make version numbers consistent, finally.

Also some small tracing fixes and a fix to the ASDF-file-writing code.

require-module: fix needs silliness around source

Loading source should now work better.

require-module: needs changes

needs has changed to rebind *module-path-descriptions* to an appropriate value at compile & load time (the values are different at these times). This is a slightly incompatible change as it means assigning to this in a file being loaded will get lost. It also rebinds it, to itself, at other times, to be consistent.

This change deals with the fact that it's never right for needs to depend on any combination of *load-truename* and *compile-file-truename* without using eval-when.

trace option to require-module

require-module now has a trace option: this produces much less output than verbose, and also directs it to *trace-output*. So if you want to see what's going on without being overwhelmed, (require-module ... :trace t) is a good way.

Also some tests have been added to the published repo (this would have been 7.1.0 but was overtaken by 7.2.0).

Writing ASDF system definitions for submodules

There's a new tool asdf-module-sysdcls which will let you write ASDF system definitions for single-file modules. It's particularly useful for things like this collection of modules and my hax collection, where there are a lot of individual single-file systems.

A new tool: deprecations

deprecations allows you to define functions, generic functions, macros and symbol macros as deprecated. When code which uses these is compiled then one or both of two things happens:

• a warning is signalled by default at compile time, with the warning being of a documented class, so that it can be handled by user code if need be;
• the file where the deprecated code is used is noted against the deprecated code, and this record can be used later, or reports generated.

The compile-time warnings can be inhibited, and the recording of users of deprecated code can be scoped dynamically. There are no run-time effects: deprecated functionality is identical to non-deprecated functionality at run-time.

As an example, given a file x.lisp:

(define-deprecated-generic-function bar (x)
  (:documentation "use fish")
  (:method (x)
   x))

(define-deprecated-function foo (x)
  "use new-foo"
  (bar x))

(defun bone (x)
  (foo x))

Then

> (compile-file "x.lisp")
[...]
;;;*** Warning in foo: deprecated generic function bar in /private/tmp/x.lisp (use fish)
[...]
;;;*** Warning in bone: deprecated function foo in /private/tmp/x.lisp (use new-foo)

Or:

> (with-deprecations (:inhibit t)
    (compile-file "x.lisp")
    (report-deprecations))
[...]
/path/to/x.lisp:
 generic function bar (use fish)
 function foo (use new-foo)

Two new tools: module builder and feature expressions

build-modules provides a way to compile installed copies of ,usually, single-file modules, relying on locate-module to find the installed copy. It's not very interesting.

feature-expressions is more interesting, and provides ways of reasoning about feature expressions after read-time. For instance you can say, at toplevel in some file to be compiled

(ensuring-features
  ((:compile-toplevel :load-toplevel :execute)
   (and :lispworks :cl-ppcre))
  ((:compile-toplevel)
   :my-macro-only-package))

Which will ensure that the file will work only on LispWorks with CL-PPCRE loaded, and also that the :my-macro-only-package is present at compile time, but not necessarily at load time.

There is also a function to evaluate feature expressions, and a case-like macro to dispatch based on features.

4.2.1: fix idiot bug in recursion

This just fixes a completely stupid and embarrassing bug in 4.2. This is why things need test suites (which it has, sort of, but a completely inadequate one).

Fallback loaders & recursion for module requiring

For require-module, *module-fallback-loaders* provides a default list of fallback loader functions. If any of them returns true then the module is assumed to be loaded. The fallback argument to require-module now provides a last-resort fallback: if nothing else has loaded the module, it is called, and blindly assumed to have loaded it.

Verbosity is now a little less verbose: you can get it to be as verbose as it was by asking for debugging too.

require-modules, together with its wrappers requires and needs will now recurse which makes providing default arguments easier, especially in needs.