Re: [pdf-devel] Compiling for windows

[jemarch]

Hi Aleks.

   I prepared a new set of files (nocheck.c and nocheck.h) that emulate the
   behavior of the Check framework. The file nocheck.h includes type and
   function definitions more or less as in the real check.h, only those
   that we are actually using. This built-in `No-Check' runs each test with
   some limitations (like no-forking).

   The good thing is that we DON'T need to modify the unit test files, as
   the API used is equivalent in check.h and nocheck.h (just avoid
   including check.h, and include the new runtests.h instead).

I think this is a quite good solution. 

It is easy to implement the writting of the `ut.log' logfile? It is
important if we want to automatically run the testsuite and process
the output.

   Here's a sample output obtained with No-Check:

   [No-Check] Running all suites...
   [No-Check] Running suite 'alloc'...
   [No-Check] Running suite 'list'...
   [No-Check] Running test case 'pdf_list_create'...
     |--> [No-Check] Running test 'pdf_list_create_001'...
     |--> [No-Check] Running test 'pdf_list_create_002'...
     |--> [No-Check] Running test 'pdf_list_create_003'...
   [No-Check] Running test case 'pdf_list_size'...
     |--> [No-Check] Running test 'pdf_list_size_001'...
   [No-Check] Running test case 'pdf_list_add_first'...
     |--> [No-Check] Running test 'pdf_list_add_first_001'...
           |--> [No-Check] base/list/pdf-list-add-first.c:53: 'Failure
   'pdf_list_size(list) != 1' occured
           |--> [No-Check] base/list/pdf-list-add-first.c:56: 'Failure
   'pdf_list_size(list) != 2' occured
     |--> [No-Check] Running test 'pdf_list_add_first_002'...
   [No-Check] Running test case 'pdf_list_add_at'...
     |--> [No-Check] Running test 'pdf_list_add_at_001'...
     |--> [No-Check] Running test 'pdf_list_add_at_002'...
   [No-Check] Running test case 'pdf_list_add_last'...
     |--> [No-Check] Running test 'pdf_list_add_last_001'...

Would be good to use the same output format than check here.

   One limitation is that due to the fact that no fork is done when
   running the tests, there is no way to recover from a segfault in
   the test (Check handles this situation correctly and sets the test
   as 'Error').

Well, that limitation is quite reasonable. We _dont_ want to write a
check replacement for windows :)

   The developer can choose at configure level whether to run the unit
   tests with the real Check framework (if available) or with the No-Check 
   framework:

   ./configure                    --> Use Check if available
   ./configure --enable-nocheck   --> Use built-in No-Check

Good. The user will be able to run the test suites even if check is
not installed in the system.


   #ifdef HAVE_NOCHECK
   #include <nocheck.h>
   #else /* If not... use standard Check Framework */
   #include <check.h>
   #endif

I would put the nocheck code in torture/nocheck/ and change the name
of the header file to `check.h'. In that way you can select which
header is used in Makefile.am using the AM_CPPFLAGS variable. The
little library in torture/nocheck could compile to a static archive
libnocheck.a 

What do you think?

   > #Check for Check and No-Check :-)

:D!

   > /* The stream module suite crashes... and if the No-Check built-in utility 
is
   >  *  used, it prevents from running further suites (no fork is done for each
   >  *  test, so it is disabled until corrected */

Please insert a new task in the flyspray installation for fix it and
put it in the WAITING state (there is a change in the stm design that
need the filesystem module implementation). In that way we wont forget
this issue :)

   < #include <check.h>
   ---
   > #include <runtests.h>

Ah ok :)

As I noted before I would prefer to simply include <check.h> and do
the trick with the preprocessor options. I dont like unit tests to
have a dependency in a specific driver (such as runtests.[ch]).

Great work Aleks :)

Many thanks.

-- 
Jose E. Marchesi  <address@hidden>
                  <address@hidden>

GNU Spain         http://es.gnu.org
GNU Project       http://www.gnu.org