Re: [pdf-devel] FS#108 (and flyspray)

[jemarch]

Hi Pablo.

   Greetings. I just replied to a NO-REPLY. Sorry for that. Even if I
   wanted to take FS#108, I realised I don't have a flyspray account!

I just created an account for you.  Please find the details in a
private email.

        I've managed to compile check with i586-mingw32msvc and pay the
   unit tests a try. Results were rather good, although there are some
   things that went wrong. I hope this helps.

Nice, thanks.

   First, make check tries to run torture/unit/runtests.exe, this won't
   get the tests to run as they seem to need to be run via the
   torture/unit/runtests libtool wrapper script. To make a hot run, I
   just forced the program name in torture/unit/Makefile to not include
   $(EXEEXT), so that it ran runtests instead of runtests.exe. This
   worked fine for running the tests, although there were some problems
   with how they ran. Can this be cleanly fixed?

I am not sure.  It seems like a bug to me.  I will make some simple
tests with automake/libtool.

        The first time, the tests ran (with some failures) until a page
   fault came up trying to run pdf_stm_write_015. Curiously this one and
   pdf_stm_write_016 (which also brings up this page fault) are fixtured
   test cases. The execution doesn't even reach the test code (found that
   out by placing some debug printfs), so I think this must have
   something to do with check's abilities to run fixtures under wine.
   Didn't try it in windows, though.

Can you send a bug report to the 'check' development mailing list,
including details about how to reproduce the problem using libgnupdf?

   For the sake of completeness, I took these two tests out and ran
   everything again. This time everything ran fine, with some of wine's
   internal whinings and some test failures, but no page faults. I
   attached make's full output and the log from check's run without the
   fixtured test cases.

I see that 'pdf_time_from_string_006' is failing.  Are you using a
recent bazaar checkout?

   Well. This report is not following any protocols about how things
   should be done, but hey, I got some free time and decided to give it a
   try, and thought you would like to know about the results.

Quite useful :)

   Oh, and I almost forgot. This was run with CK_FORK="no" in its
   environment.

What happens if you try to run in mingw32 with CK_FORK="yes"?  AFAIK
the running of the tests in different processes is not supported in
'check' when running in windows.

-- 
Jose E. Marchesi    address@hidden
GNU Project         http://www.gnu.org