clisp support [Re: Pushed ASDF 18.104.22.168: fixes for CLISP, etc.]
rpgoldman at sift.net
Fri Sep 2 03:23:32 UTC 2016
On 9/1/16 Sep 1 -9:57 PM, Sam Steingold wrote:
>> * Robert Goldman <ectbyqzna at fvsg.arg> [2016-09-01 18:38:12 -0500]:
>> On 9/1/16 Sep 1 -6:15 PM, Sam Steingold wrote:
>>>> * Robert Goldman <ectbyqzna at fvsg.arg> [2016-09-01 12:34:11 -0500]:
>>>> Even worse, AFAICT clisp does not make its version number available to
>>>> the lisp context.
>>> CLISP, like all the other implementations striving for ANSI CL
>>> compliance, exports `lisp-implementation-version'
>>> However, testing version numbers is not the best way to achieve
>>> cross-release compatibility; it is much better to test for specific
>> True, but this is not for code -- it's for regression testing. For
>> regression-testing, I think it's fine if we say "on clisp, if the
>> version is less than or equal to 2.49, disable this test."
>> Until now we have just been saying "on clisp, disable this test."
>> Unfortunately, since I believe that clisp in git has not been bumped
>> beyond 2.49, reading LISP-IMPLEMENTATION-VERSION may not solve our problem.
> lisp-implementation-version does provide the information you seek.
> the released version is 2.49, the development is 2.49+.
> we use hg, not git.
OK. Sorry -- I realize I am being fussy, but it's a lot easier for us if
we can have something like
(version>= (clisp-implementation-version) "2.49.0")
which works as do all ASDF version numbers, on the \d+ (. \d+)* pattern.
If we have to wrestle with clisp's "2.49+" and someone else's "2.50rc"
and someone else's "2.50beta3", it's just crazy-making and unsustainable.
If there is another standard that people are adhering to, I'd be
interested in ASDF supporting it, but not one version numbering scheme
per implementation. Well, it's not the scheme per se, it's the need for
us to maintain a >= relationship for each such scheme.
More information about the asdf-devel