jamesjb@jamesjb.com writes:
It would be nice to figure out how to get the ASDF system to compile the DLL on Windows.
That would be a bad idea. Presumably most users of CFFI on MS-Windows don't have MS-VC (or Mingw). But IMHO all users should be entitled to run a testsuite.
I'm not sure I'd want to include the DLL in the repository as the risk of it not getting updated when the testsuite is updated is somewhat high [...]
IMHO not really a problem, because the .dll will stabilize, while the testsuite will continue to grow.
Strict solution: add a version number (foreign-var) to the .dll and check it when loading the testsuite. Then people will know when it is outdated and hope for a new one from the CFFI site. As I said, presumably the .dll will receive seldom updates.
Regards, Jorg Hohle.
"Hoehle, Joerg-Cyril" Joerg-Cyril.Hoehle@t-systems.com writes:
[ putting libtest.dll in the darcs tree ]
Strict solution: add a version number (foreign-var) to the .dll and check it when loading the testsuite. Then people will know when it is outdated and hope for a new one from the CFFI site. As I said, presumably the .dll will receive seldom updates.
This sounds like a reasonable plan to me---would any Windows users like to implement this? I probably won't be able to get to it for awhile...
James
On 2/10/06, James Bielman jamesjb@jamesjb.com wrote:
Joerg-Cyril wrote:
Strict solution: add a version number (foreign-var) to the .dll and check it when loading the testsuite. Then people will know when it is outdated and hope for a new one from the CFFI site. As I said, presumably the .dll will receive seldom updates.
This sounds like a reasonable plan to me---would any Windows users like to implement this? I probably won't be able to get to it for awhile...
I'll volunteer, and I might make some progress this weekend. I haven't looked at the testsuite code yet, but I suspect the DLL export declaration is needed for various function definitions (this can be hidden behind a pre-processor macro).
-- Jack Unrue
On 2/10/06, I wrote:
On 2/10/06, James Bielman jamesjb@jamesjb.com wrote:
Joerg-Cyril wrote:
Strict solution: add a version number (foreign-var) to the .dll and check it when loading the testsuite. Then people will know when it is outdated and hope for a new one from the CFFI site. As I said, presumably the .dll will receive seldom updates.
This sounds like a reasonable plan to me---would any Windows users like to implement this? I probably won't be able to get to it for awhile...
I'll volunteer, and I might make some progress this weekend. I haven't looked at the testsuite code yet, but I suspect the DLL export declaration is needed for various function definitions (this can be hidden behind a pre-processor macro).
...which I might have realized is already done had I actually comprehended earlier replies in this thread. So I'll implement the version number foreign-var and corresponding check, and post a patch, unless someone beats me to it.
-- Jack
On 2/10/06, James Bielman jamesjb@jamesjb.com wrote:
"Hoehle, Joerg-Cyril" Joerg-Cyril.Hoehle@t-systems.com writes:
[ putting libtest.dll in the darcs tree ]
Strict solution: add a version number (foreign-var) to the .dll and check it when loading the testsuite. Then people will know when it is outdated and hope for a new one from the CFFI site. As I said, presumably the .dll will receive seldom updates.
This sounds like a reasonable plan to me---would any Windows users like to implement this? I probably won't be able to get to it for awhile...
James
Please find attached a darcs patch that adds a simple version check in the testsuite against libtest.dll. The actual check itself is declared via another deftest called dll.version.check. The version string is currently "060209" and when that needs to be changed, you need to edit bindings.lisp and libtest.c.
Since this is my first patch for CFFI and my first time using darcs, please do point out any mistakes that need to be corrected and I will be happy to do so.
-- Jack Unrue
Jack Unrue jdunrue@gmail.com writes:
Please find attached a darcs patch that adds a simple version check in the testsuite against libtest.dll. The actual check itself is declared via another deftest called dll.version.check. The version string is currently "060209" and when that needs to be changed, you need to edit bindings.lisp and libtest.c.
Cool, thanks. An alternative would be to actually signal an error explaining that the DLL is outdated instead of just failing one test. What do you think?
On 2/11/06, Luís Oliveira luismbo@gmail.com wrote:
Cool, thanks. An alternative would be to actually signal an error explaining that the DLL is outdated instead of just failing one test. What do you think?
Yep, I agree that's better. Updated patch attached.
-- Jack Unrue
On 2006-feb-12, at 17:57, Jack Unrue wrote:
<libtest-version-check-v2.patch>
One last detail :-), I haven't actually tried the patch but I think that EVAL-WHEN is not necessary. Or am I missing something?
On 2/12/06, Luís Oliveira luismbo@gmail.com wrote:
One last detail :-), I haven't actually tried the patch but I think that EVAL-WHEN is not necessary. Or am I missing something?
You're right, thanks. Revised patch attached.
-- Jack Unrue
Jack Unrue jdunrue@gmail.com writes:
You're right, thanks. Revised patch attached.
Sorry it took me a few days to look at this---I think this looks good, but I'd suggest changing DEFCONSTANT to DEFPARAMETER since according to a strict interpretation of the standard you can't redefine a constant to a non-EQL value (SBCL will complain about this IIRC).
Also, I'd suggest putting the full year in the version string "20060210" to make it a little more obvious what order the fields are in.
Thanks, James
On 2/12/06, James Bielman jamesjb@jamesjb.com wrote:
Sorry it took me a few days to look at this---I think this looks good, but I'd suggest changing DEFCONSTANT to DEFPARAMETER since according to a strict interpretation of the standard you can't redefine a constant to a non-EQL value (SBCL will complain about this IIRC).
Also, I'd suggest putting the full year in the version string "20060210" to make it a little more obvious what order the fields are in.
OK, I made both changes. Revised patch attached.
BTW, I uploaded the DLL (compiled with VC++ 2005) to this location:
http://home.earthlink.net/~jdunrue/libtest.dll
-- Jack Unrue
On 2006-feb-08, at 16:55, Hoehle, Joerg-Cyril wrote:
jamesjb@jamesjb.com writes:
I'm not sure I'd want to include the DLL in the repository as the risk of it not getting updated when the testsuite is updated is somewhat high [...]
IMHO not really a problem, because the .dll will stabilize, while the testsuite will continue to grow.
Maybe, maybe not. Who knows? :-)
It just occured to me that providing a pre-compiled DLL sort of discourages people from building their own with different compilers (eg: MSVC vs Mingw). Not sure if that's good enough a reason not to provide the DLL, probably not.
-
Hoehle, Joerg-Cyril -
Jack Unrue -
James Bielman -
Luís Oliveira