Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Building a _local_ system #2

Open
iamFIREcracker opened this issue Nov 25, 2021 · 0 comments
Open

Building a _local_ system #2

iamFIREcracker opened this issue Nov 25, 2021 · 0 comments
Assignees

Comments

@iamFIREcracker
Copy link

Currently, there are at least two different ways of dealing with locally defined systems, i.e. systems defined in the working directory:

  1. Create a symlink inside ~/quicklisp/local-projects (or ~/common-lisp), pointing to the current directory
  2. Add the current directory to ASDF:*CENTRAL-REPOSITORY* ((pushnew '*default-pathname-defaults* asdf:*central-registry*))

Now, with the first option, everything works as expected: you call TRIVIAL-BUILD:BUILD, it spawns a new CL image, it runs ASDF:LOAD-SYSTEM in it, and since the current directory is inside ~/quicklisp/local-projects (or ~/common-lisp), your system will be loaded just fine.

Unfortunately the current implementation does not seem to play nicely with the second option, i.e. updating ADSF:*CENTRAL-REPOSITORY*; that's because the newly spawn CL image, the one in which ASDF:LOAD-SYSTEM is called, has ASDF:*CENTRAL-REPOSITORY* in its default state, i.e. without our customizations.

Is there any interest in supporting this use case, or instead you prefer to push people to use option 1 instead? Because if there was, here is how I patched LOAD-AND-BUILD-CODE (note the line right above the ASDF:LOAD-SYSTEM call):

  • I serialize the current value of ASDF:CENTRAL-REGISTRY, in reverse order, so while loading them later with PUSH, the original order is preserved; note: this happens on the host image, i.e. the one where :CERAMIC is run
  • For each entry, I push it back into ASDF:CENTRAL-REGISTRY -- this instead is run on the final app image, the newly spawned one
(defun load-and-build-code (system-name entry-point binary-pathname)
  "Return a list of code strings to eval."
  (list
   "(setf *debugger-hook* #'(lambda (c h) (declare (ignore h)) (uiop:print-condition-backtrace c) (uiop:quit -1)))"
   (format nil "(dolist (entry '~W) (push entry asdf:*central-registry*))" (reverse asdf:*central-registry*))
   (format nil "(asdf:load-system :~A)" system-name)
   (format nil "(setf uiop:*image-entry-point* #'(lambda () ~A))"
           entry-point)
   (format nil "(uiop:dump-image ~S :executable t
  #+sb-core-compression :compression #+sb-core-compression t)"
           binary-pathname)))

Let me know if you see any problems with this and most importantly if you find this somewhat interesting, in which case, I would not mind creating a pull request for this.

Ciao,
M.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants