>> I think that at this point it would be a good idea to check if the >> latest version of check.sf.net <http://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"?
He means supporting Windows compilation, either with mingw32, cygwin or directly compiled in Windows. > > 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 Yes, current check compiles in w32, but still lacks of forking support. > > Adding > > srunner_set_fork_status(sr, CK_NOFORK); Better to put the envvar CK_FORK=no instead of modifying runtests.c to always run in no-forked mode. So maybe Jose is right and we should skip using no-check from now on? > > 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. Of course, if you have a w32 machine and you want to test them there, it's perfect. Cheers! -Aleksander
