Чт 30 апр 2020 @ 12:42 Jonas Smedegaard <d...@jones.dk>: > Quoting Jan Wielemaker (2020-04-30 11:40:32) >> On 4/28/20 5:26 PM, Jonas Smedegaard wrote: >> > Quoting Jan Wielemaker (2020-04-28 16:56:30) >> >> >> That is worth a try. I guess that implies that generating >> >> SWI-Prolog (as package) also generates this hash. What kind of >> >> support would be needed from SWI-Prolog to make this work? Some >> >> script/command to create this hash for a particular system? >> > >> > Thanks for your interest in this challenge :-) >> > >> > Yes, if ABI is computed during build then what would be helpful is >> > to extend that to expose the computed ABI as a single string. Maybe >> > add it as an additional note in output of "swipl --version"? >> > >> > Or if possible to (re)compute at runtime then just document that, >> > for us distribution maintainers to integrate into our packaging >> > routines. >> >> I think I cover this nicely now: >> >> janw (linux; master) 68_> swipl --abi_version >> swipl-2-67-792e14f8-de23899e >> >> There is a section in the docs explaining the various binary ABIs and >> what aspects rely on them. There is a new function PL_version() in >> the C api that can be used to query the versions individually. >> The above says: >> >> - Backward compatibility version of the foreign interface is 2 >> - Saved state file format can be loaded when not older than 67 >> - 792e14f8 is a fingerprint for the C-defined foreign predicate >> signatures. >> - de23899e is a fingerprint of the VM instructions and their >> signatures. >> >> Does this adequately solve your problems? Do you see other >> requirements? >> >> Can you test on this, or would you rather wait for an official >> 8.1.30? I can create that now if that is useful to speedup >> stabilizing stuff to get at 8.2.0. > > That sounds really great. Thanks! > > I _think_ above described interfaces and documentation is enough for > implementing the most elegant packaging that I can imagine. > > @Lev, would you be willing to make a development snapshot (e.g. targeted > Debian experimental) then I am fine playing with that for refining an > elegant packaging mechanism. Or if you would prefer only releasing > official code then please say so. Or say if you are too busy to playing > with this now - there is no hurry from my side :-)
I would prefer next release, 8.1.30, but since I will have time for it only next week (or maybe on coming Sunday) there's no hurry for Jan too (I mean to tag 8.1.30). Cheers! Lev
