Re: [pdf-devel] "Hello" and questions

[Aleksander Morgado]

>> 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