Setting environment variables

[Robert Goldman]

`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 at 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."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/armedbear-devel/attachments/20230503/c7fa342c/attachment.html>