Re: Coverage for libltdl/slist.c and fallout

[Peter Rosin]

Den 2009-11-29 22:27 skrev Ralf Wildenhues:

*snip*

> - In the end I grew really lazy and added the new test to the old
> testsuite: that seemed the easiest way to integrate and catch all the
> compilation and include flags from toplevel Makefile.am in order to
> build and use a separate slist.o object.  If this is not ok with you,
> then please complain loudly.

Whispering a complaint, see below...

*snip*

>     Test and fix slist.c.
>     
>     * libltdl/libltdl/slist.h: Include stddef.h, for size_t.
>     (slist_remove): Return pointer to SList, not void.
>     * libltdl/slist.c: Include stdlib.h, for malloc and free.
>     (slist_remove): Adjust prototype as above.
>     (slist_sort): Do not loop forever on one-item list.
>     * tests/test-slist.c: New file.

This will be the first .c file in the tests directory, is that
really desirable at this point? All other .c files for the old
testsuite are in subdirs. But adding yet another subdir is not
what I want either. bootstrapping takes forever as it is and
that's the reason I don't want another directory, I want fewer,
and I want the old testsuite to go away ASAP. But that said,
I'd rather have my MSVC patches reviewed of course (since you
asked me to not fix MSVC issues in the old testsuite I'm not
regularly running it anyway, instead usually bootstrapping
with reconfdirs='. libltdl'...)

>     * Makefile.am (COMMON_TESTS): Add tests/test-slist.
>     (check_PROGRAMS, tests_test_slist_SOURCES): New variables.

Shouldn't this new file end with .test as all other such files in
the old testsuite? I also miss this file from the patch. Ahhh, is
the testsuite running the produced executable? Does that work
when doing a cross build? What about $EXEEXT?

Cheers,
Peter

--
They are in the crowd with the answer before the question.
> Why do you dislike Jeopardy?