Skip to content
GitLab
Explore
Sign in
Register
Primary navigation
Search or go to…
Project
A
asdf
Manage
Activity
Members
Labels
Plan
Issues
Issue boards
Milestones
Wiki
Code
Merge requests
Repository
Branches
Commits
Tags
Repository graph
Compare revisions
Snippets
Build
Pipelines
Jobs
Pipeline schedules
Artifacts
Deploy
Releases
Container Registry
Model registry
Operate
Environments
Monitor
Incidents
Service Desk
Analyze
Value stream analytics
Contributor analytics
CI/CD analytics
Repository analytics
Model experiments
Help
Help
Support
GitLab documentation
Compare GitLab plans
Community forum
Contribute to GitLab
Provide feedback
Terms and privacy
Keyboard shortcuts
?
Snippets
Groups
Projects
Show more breadcrumbs
Jan Moringen
asdf
Commits
8761392e
Commit
8761392e
authored
11 years ago
by
Francois-Rene Rideau
Browse files
Options
Downloads
Patches
Plain Diff
Update TODO: more on cross-compilation, deferred-warnings, etc.
parent
b54f9033
No related branches found
No related tags found
No related merge requests found
Changes
1
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
TODO
+65
-16
65 additions, 16 deletions
TODO
with
65 additions
and
16 deletions
TODO
+
65
−
16
View file @
8761392e
* 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.
...
...
This diff is collapsed.
Click to expand it.
Preview
0%
Loading
Try again
or
attach a new file
.
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Save comment
Cancel
Please
register
or
sign in
to comment