From a720e02f09309f2826692d23b95f5ce83d462d90 Mon Sep 17 00:00:00 2001 From: Francois-Rene Rideau <tunes@google.com> Date: Thu, 19 Dec 2013 16:00:50 -0500 Subject: [PATCH] Update TODO --- TODO | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/TODO b/TODO index 3464bd07d..8fa2ef917 100644 --- a/TODO +++ b/TODO @@ -1,10 +1,8 @@ * Decree that versions older than 2 years are not supported, remove them from upgrade tests. We should already not support anything older than 2.014.5 from Quicklisp, or so. - Yet, we should keep supporting upgrading from what vendors provide. - -* Improve upgrade so that we don't lose state when upgrading from a "recent enough" ASDF. - This requires better upgrade tests, with hot data. + Yet, we should keep supporting upgrading from what vendors provide + — so push them to provide recent stuff. * ASDF 3.2: moving toward cross-compilation. This would allow to get all or most of the benefits of XCVB @@ -13,10 +11,13 @@ ** 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 form that must be evaluated on the target machine, not the host. - A trivial that runs on the target - and doesn't require ASDF or CLOS installed there (though maybe UIOP). -** Audit all the current users of perform, and offer them a new way; + A trivial that runs on the target and doesn't require the network + of objects related to the ASDF plan to be present, + or even ASDF itself, for the matter (though UIOP, yes, for sanity). +** 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. +** Modify SBCL and other implementations so they provide UIOP + independently from ASDF? * Some out-of-line configuration mechanism for various options? i.e. have files that override some variables around compilation of some systems. -- GitLab