`ASDF:MAKE` is a wrapper function that can do `LOAD-SYSTEM` or other things through some complex configuration process. I think the intent is to let the user specify that the `MAKE` operation might actually involve building an executable, a library, or some other thing (particularly for the C-based implementations).
So you could require the `asdf:make` on `"use-posix-syscalls"` to do something like build a `.jar` file or some JNI whatchamacallit.
But if it's just going to do `load-system`, I'd encourage you to simply tailor the behavior of the `load-op`. `make` is a new layer of complexity, which you should avoid unless you need it.
Best, R
On 3 May 2023, at 10:30, Mark Evenson wrote:
On May 2, 2023, at 21:16, Alan Ruttenberg alanruttenberg@gmail.com wrote:
[…]
It's true that I use aio. TBH I've never understood the point of separating the contribs from the base. File size isn't an issue any more. What's the upside of splitting them apart? A bit of extra time indexing the classes in the jar?
From https://github.com/armedbear/abcl/blob/master/doc/packaging-abcl.org :
We create two separate jar artifacts in order to: • To place an upper bound of size of abcl.jar regardless of what we package in abcl-contrib.jar. • Clearly mark which parts of the code-base are covered under GPLv2+classpath from those that may have other licensing terms. By making the loading of “contrib” a dynamic operation, we defer possible infringement to the User who redistributes the resulting jar artifact.
Conceptually, we should somehow place the implementation of setting environment variables via the C syscall as a patch in the contrib system in a new contrib called (?) USE-POSIX-SYSCALLS (terrible name, please change). Such a new contrib would a) depend on JNA and b) have to be used via
(asdf:make :use-posix-syscalls)
I don't know what asdf:make does. I tried it in a situation (autoloading the java parser when #1 was used the first time) where I expected it to load a system and it didn't seem to.
ASDF:MAKE is a shorter synonym for ASDF:LOAD-SYSTEM as far as I understand things.
Would it be sufficient to do something like:
(defun ensure-jna-loaded () (or *jna-loaded* (progn (when (not (ignore-errors (find-java-class 'jna.nativelibrary))) (require 'abcl-asdf) (add-to-classpath (funcall (intern "RESOLVE" 'abcl-asdf "net.java.dev.jna/jna/LATEST"))) (setq *jna-loaded* t)))))
Probably not: you really want to depend on the ASDF encapsulation of JNA in 'contrib/mvn/jna.asd’, not the presence of yet another special (“*jna-loaded*”). Since you are requiring ABCL-ASDF:RESOLVE to be present, you can make the assumption that both ASDF and ABCL-CONTRIB have been successfully REQUIREd.
[…]
Bottom line is that I don't know how to package this under whatever the assumptions are when not using abcl-aio
Alright. I will try to take a stab at this after I figure out the way forward with the Gray streams/SLIME imbroglio.
-- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now."