Commit 8761392e authored by Francois-Rene Rideau's avatar Francois-Rene Rideau

Update TODO: more on cross-compilation, deferred-warnings, etc.

parent b54f9033
* Decree that versions older than 2 years are not supported, * Decree that versions older than 2 years are not supported;
maybe remove them from upgrade tests yet, keep supporting an upgrade from whatever vendors provide
(or split upgrade tests in two test sets: short and long).
We should already not support anything older than 2.019 or so
(still used by LispWorks).
Yet, we should keep supporting upgrading from what vendors provide
— so push them to provide recent stuff. — so push them to provide recent stuff.
Already, swank-asdf doesn't support anything older than 2.014.6
(as provided by the first 2011 iteration of Quicklisp), and
I (fare) am pushing for swank-asdf to not support anything older
than 2.019 (still used by LispWorks 6.1).
Hopefully, sometime in 2014, everyone will have adopted ASDF 3.
Maybe remove old versions from upgrade tests; or maybe not:
if we support old versions in any way,
it should be for upgrade only, and "punt" is acceptable.
Upgrade tests might be split in two test sets: short and long.
* Moving toward cross-compilation (ASDF 3.2?) * Moving toward cross-compilation (ASDF 3.2? 4?)
This would allow to get all or most of the benefits of XCVB This would allow to get most of the benefits of XCVB
(reproducibility, scalability, applicability to mobile platforms, etc.), (reproducibility, scalability, applicability to mobile platforms, etc.),
except without the backward incompatibility of XCVB. except without the backward incompatibility of XCVB.
NB: the MOCL author would benefit a lot, and might chip in.
** Need to further split asdf:perform in two parts: ** Need to further split asdf:perform in two parts:
A part that runs on the host and specifies (as SEXP or string to read) A part that runs on the host and specifies (as SEXP or string to read)
a form that must be evaluated on the target machine, not the host. forms that must be evaluated on the target machine, not the host:
A trivial that runs on the target and doesn't require the network (asdf:perform-forms target operation component)
of objects related to the ASDF plan to be present, The default implementation can fallback to running the
or even ASDF itself, for the matter (though UIOP, yes, for sanity). (asdf:perform operation component) on the target,
which if it is on specially crafted operation and component objects
that do not require recreating the component hierarchy and plan,
but still require loading the defsystem-depends-on dependencies:
on the target:
(defmethod perform-forms ((target null) operation component)
;; null target designates current image
`((asdf:perform ',op ',comp)))
(defmethod perform-forms ((target external-target) operation component)
;; external target means a cross compiler
`((require :asdf)
(map () 'asdf:load-system '(,defsystem-deps))
(asdf:perform ,(fake-operation-form operation)
,(fake-component-form component))))
The other way around the default perform method could be:
(defmethod perform ((o t) (c t))
(let ((forms (perform-forms nil o c)))
(if (equal forms
`((asdf:perform ',o ',c)))
(error "Missing perform method on ..." ...)
(map () 'eval-thunk forms))))
Note that in the general case, there are multiple forms,
that must be provided on the command line somehow
(see the lisp-invocation system and also how cl-launch does it),
with packages necessary to read latter forms being
created by former forms, so you cannot read everything in one go.
ASDF or at least UIOP should probably be provided in the target
image by default, anyway, without needing to be explicitly specified.
A more declarative interface to needing the defsystem-deps
is probably useful.
** A real cross-compiling backend that works the way of XCVB
would need to compute a complete graph for the plan,
which could be achieved by inheriting from the code in POIU.
Thinking about it, the cross-compiling target object
could actually be the same as the plan object.
The basic case of in-image execution would need to be in ASDF,
while the actual cross-compilation case would be in an extension.
** Audit all the current specializers of perform, and offer them a new way; ** Audit all the current specializers of perform, and offer them a new way;
they can keep the perform method to run on older versions of ASDF. they can keep the perform method to run on older versions of ASDF.
** Modify SBCL and other implementations so they provide UIOP ** Modify SBCL and other implementations so they provide UIOP
...@@ -95,9 +141,11 @@ ...@@ -95,9 +141,11 @@
* fix directory-files to not return directories on CCL, etc. Add tests. * fix directory-files to not return directories on CCL, etc. Add tests.
* use cl-test-grid to see if asdf-user can :use most (all?) of UIOP. * use cl-test-grid to see if asdf-user can :use most (all?) of UIOP.
Unhappily, on SBCL, sb-grovel uses asdf and sb-ext, SB-GROVEL used (until 25c1769 from 2013-02-23) to :use both ASDF and
which causes a clash with run-program. SB-EXT, which prevents ASDF from exporting RUN-PROGRAM, but
Or has this been changed long enough ago? Can it be special-cased? should not be a problem with ASDF-USER :use'ing UIOP.
A run of quicklisp is necessary, with an eye also for warnings
from .asd's that might be overriding definitions in UIOP(!)
* have a mode to explain WHY a component needs to be recompiled. * have a mode to explain WHY a component needs to be recompiled.
...@@ -236,7 +284,7 @@ It looks like SWANK can be fixed soon, though, so we'll see. ...@@ -236,7 +284,7 @@ It looks like SWANK can be fixed soon, though, so we'll see.
*** com.clearly-useful.generic-collection-interface => :com.clearly-useful *** com.clearly-useful.generic-collection-interface => :com.clearly-useful
*** metatilities *** metatilities
=> :ait-timeout :system-applicable-p => :ait-timeout :system-applicable-p
*** ucw ucw-core *** ucw ucw-core
=> =>
version version
...@@ -247,6 +295,7 @@ It looks like SWANK can be fixed soon, though, so we'll see. ...@@ -247,6 +295,7 @@ It looks like SWANK can be fixed soon, though, so we'll see.
* deferred-warnings support probably needs to be redone better. * deferred-warnings support probably needs to be redone better.
* implement deferred warnings support on lispworks * implement deferred warnings support on lispworks
* turn undefined function style-warnings into full warnings(?)
* work with cl-test-grid to eliminate deferred warnings from quicklisp libraries * work with cl-test-grid to eliminate deferred warnings from quicklisp libraries
* https://www.mail-archive.com/asdf-devel@common-lisp.net/msg03608.html * https://www.mail-archive.com/asdf-devel@common-lisp.net/msg03608.html
* czak@google.com rewrote part of deferred warnings support. * czak@google.com rewrote part of deferred warnings support.
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment