I just noticed you added the PL_version() foreign interface function to get information about the abi versions, as well as the --abi_version command line option to get the same information.
Just a couple of suggestions (since I know you are ready to make the stable version)
Could you also provide a prolog predicate (or maybe prolog flags) to return the ABI versions? This will allow access to ABI versions from within prolog.
Perhaps the command line option --abi_version should be renamed to --abi-version to be consistent with other command line options which use - as the word separator (such as --dump-runtime-variables
Thought about that, but I’m not really sure what the use case is, so for now I thought to wait and see until someone comes up with a use case.
Not sure. It is already inconsistent. There is also --stack_limit and --stand_alone, etc. Some of this is because they map directly to Prolog constants and these are typically written using an underscore. Possibly option names should handle - and _ as equivalent?
The idea is to manage releases of binary packs from within prolog itself, so we can control the generation of binary compatible packs (e.g. including qlf files and/or .so files) from a prolog program that is responsible for compiling and generating a binary pack release. The prolog program will then be able to start, if necessary, older versions of SWI-Prolog to provide an array of binary releases of packs.
There is another use case, but I can’t talk much about it. It involves generating binary compatible SWI-Prolog data structures directly from prolog (bypassing the C api, with the exception of some special basic foreign functions that allow direct memory writing/reading). This is, obviously, out of the realm for normal prolog programming.
That is a good idea, certainly will improve cli usability.
Guess you mean C data structures? How is that different from pack ffi? Unfortunately this pack stopped working for MacOS as they put a lot of C extensions in their header files (should still work if you do not rely much on the system headers).