> I think that at this point it would be a good idea to check if the > latest version of check.sf.net is supporting mingw32 well enough to > replace nocheck. The alternative would be to implement the fixture
> capabilities in nocheck, but we don't want to write a full replacement > of check :)
Could you be more accurate about that? I mean, what did you mean with "supporting mingw32"?
For example, I've got the latest svn version of libcheck and it compiled with mingw32 cleanly. libgnupdf also compiled cleanly with this version of libcheck with mingw32, but trying to run runtests.exe through wine got me some complaint from check:
fixme:msvcrt:MSVCRT__sopen : pmode 0x6efe28 ignored Running suite(s): alloc check_run.c:168: This version does not support fork
Adding
srunner_set_fork_status(sr, CK_NOFORK);
at line 32 in torture/unit/runtests.c, rebuilding checks and running runtests.exe through wine again comes up with some tests being run and some debugs from wine. But then some segfault and wine's dump about it.
Also have to mention that I modified torture/unit/runtests to run wine runtests.exe instead of just runtests.exe.
I'd also like to know if these tests should always be run under wine and not under a win32 system, I mean, in which case are they to be considered "working"? Anyway, having already compiled them, I'll pay them a try in my XP to see what happens. I could also undo this patch that prevents nocheck from compiling and start playing with the problem stated in FS#85 so that it could be independently solved.
Though again I'd like to know which is the right path to follow from here.