Quoting Lev Lamberov (2020-04-28 09:35:31) > I've got the following response from swi-prolog upstream about the > issue: > > Вс 26 апр 2020 @ 09:30 Jan Wielemaker <j.wielema...@vu.nl>: > > > Need to think a bit about the ABI issue. Basically, saved states are > > incompatible between versions, although you can have some luck on > > closely related versions. There are two sources of trouble: change > > to the VM instruction set and changed interfaces for internal > > foreign predicates that require matching changes to the Prolog > > layer. > > > > Applications can ship themselves as .qlf file instead of saved > > states to avoid the second, although that may be complicated. The > > first is unavoidable unless I would go for strictly backward > > compatible changes to the VM. I don't think that is going to happen > > soon. The VM detects the incompatibility by adding a hash of the VM > > instructions and their declarations to the state. > > > > The normal way to deal with this (I guess) would be to distribute as > > source and do the saved state generation as part of the installation > > process. > > > > Finally, you can enable versioned lib directories such that > > SWI-Prolog is installed in /usr/lib/swipl-<version> and you can have > > multiple versions installed (and have the links from /usr/bin for > > swipl, etc select the current version). States though can depend on > > a particular version. This is much like Java, no?
Thanks for passing it upstream. Their description matches my expectation. I find it interesting that they mention a hash is used to identify VM. We could maybe expose that in a virtual package "swi-prolog-abi" that eye could then depend on. That approach would ensure no need for recompilation of eye when releasing a Debian revision *not* changing upstream ABI (as is also the behavior of current eye release), and it would require eye recompilation when releasing a Debian revision which *does* change upstream ABI (e.g. by adding/changing a patch to upstream code, something that current eye release does *not* handle correctly). Yes, there is an alternative approach of shipping source code for eye, and compile it during install (and add a trigger to recompile when Prolog package is updated). I would like to avoid that if possible: Purpose of eye is not as an extension for a Prolog _development_ environment but for semantic web processing. See also bug#959027. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: signature
