On 9/1/16 Sep 1 -6:15 PM, Sam Steingold wrote:
- Robert Goldman ectbyqzna@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' (http://clhs.lisp.se/Body/f_lisp_i.htm).
However, testing version numbers is not the best way to achieve cross-release compatibility; it is much better to test for specific behavior.
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.
If you will tell me how to distinguish between clisp 2.49 release and clisp 2.50 release candidate, I can make that happen. From my PoV, one alternative would be to just make your LISP-IMPLEMENTATION-VERSION be 2.49.1, instead of 2.49.
If I don't have a way to distinguish between 2.49 and pre-release 2.50, I am left with a choice of undesirable alternatives:
1. Go back to disabling this test on clisp, which will keep anyone from making sure that behavior will be good in your coming release or
2. Treating release clisp as unsupported and no longer testing ASDF on it.
I understand that it's not ideal, but I'm testing up to 8 lisp implementations, on three platforms. I simply cannot track the 6 open source versions off revision control systems. I must have releases, or I cannot maintain my testing discipline. Indeed, on windows, I must have binary releases, since I do not have a build environment for Windows.
Thanks, r