On May 3, 2023, at 17:30, Mark Evenson evenson@panix.com 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?
Updated the rationale on
From https://github.com/armedbear/abcl/blob/master/doc/packaging-abcl.org:
to read:
The standard ABCL build process as described in the build.xml file and executed by the Ant build tool results in two artifacts: abcl.jar and abcl-contrib.jar. abcl.jar contains all the Java and Common Lisp code necessary that constitute the ANSI conforming implementation runtime, plus the latest stable ASDF. The abcl-contrib.jar (aka contrib) artifact contains additional Common Lisp-only code that extends the implementation in useful manners.
We create two separate jar artifacts in order to:
1. To place an upper bound of size and complexity of abcl.jar regardless of what we package in abcl-contrib.jar. Having a restricted core ANSI implementation plus ASDF enables us to:
1.1. More easily bootstrap ABCL when porting to JVM runtimes other than the OpenJDK (Dalvik, CLR, )
1.2. Subsequently use ASDF to package ABCL extension components.
2. 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.