For most purposes, what the operating environment is executing the hosted JVM should be irrelevant for users of the implementation. jna.jar packages native shared objects in a variety of formats, and has reasonable code for finding the correct implementation to dynamically link, so for ABCL just defer to the use of ABCL-ASDF:RESOLVE-DEPENDENCIES.
So the jar contains multiple .so, one for each supported platform, and dispatches at runtime? e.g. a windows .dll, a mac .library, linux .so for x64 x86 (and why not arm hppa sparc, etc.), plus maybe a .so for solaris or bsd x64, sparc64, etc. Must be both cool for users a somewhat "interesting" for builders.
In this case indeed java as the OS and architecture would fit.
There seems to be something a little funky with the ABCL JAR-PATHNAME under ASDF-2.017.22, so we expect to patch for abcl-1.0.1 (within a month), so we're right on track with you. How can I test XCVB?
Don't forget to send me the patch!
XCVB support for ABCL is quite minimal: * XCVB supports ABCL as a target (though not currently as a host; portability to SBCL, CCL and CLISP is already horrible). * XCVB does not support building an executable with ABCL yet. * due to high ABCL start time, the normal XCVB building of each file in a new process is painfully slow. * XCVB can still output an ASDF for ABCL to use, but that's not very useful.
In the near future, I'll add support for "reverse slave" whereby the master who calls XCVB gets back instructions from XCVB to do the building itself; no need for a clumsy roundtrip through ASDF anymore. So XCVB can become a stand-in replacement for ASDF even when it doesn't bring any particular advantage.
To test XCVB, grab the latest release tarball with all the dependencies, compile with SBCL (preferred) with make install, and try building, say, to compile fare-utils, to make it simple, and watch it slog through:
xcvb simple-build --build fare-utils \ --lisp-implementation abcl --verbosity 99
I just tried, and I'm pleasantly surprised it just worked (though very slowly), though I haven't touched ABCL support in a while.
Can ABCL somehow start a fresh image for cheap in the same Java heap, or even better, fork a CL image within the same Java heap? That would make ABCL much more useful as an XCVB backend.
To find what platform the hosted JVM is executing under, I might suggest some variant of
CL-USER> (when (find :unix *features* ) (run-program "uname" '("-a")))
Is that useful?
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org I love deadlines. I love the whooshing sound they make as they fly by. — Douglas Adams