[PATCH/RFC] Scanner for tests

[Pekka Paalanen]

On Tue, 3 Dec 2013 11:40:19 +0100
Marek Ch <mchqwerty at gmail.com> wrote:

> Also, the UNIT_TEST define (or it's renamed alternative) have to be
> defined in both
> src/Makefile.am and tests/Makefile.am. Wouldn't it be better to
> handle this define
> via configure.ac in this case?

No, because UNIT_TEST must not be defined when compiling src/, but it
needs to be defined when compiling tests/. The approach used for matrix
"borrows" the source files from sibling directories and compiles them
separately for testing. See matrix_test_SOURCES.

UNIT_TEST is simply a switch, that alters the definition of the macro
that is used to mark the directly testable private functions.

If you think that this double compiling with different definitions is
harmful, then that's another issue.


Thanks,
pq

> On 2 December 2013 22:18, Bryce W. Harrington
> <b.harrington at samsung.com>wrote:
> 
> > On Fri, Nov 29, 2013 at 04:36:56PM +0200, Pekka Paalanen wrote:
> > > Hi,
> > >
> > > instead of writing a C language parser to copy stuff around, how
> > > about doing what was done with Weston matrix code? See:
> > >
> > > http://cgit.freedesktop.org/wayland/weston/tree/tests/Makefile.am
> > > http://cgit.freedesktop.org/wayland/weston/tree/shared/matrix.c
> > > http://cgit.freedesktop.org/wayland/weston/tree/tests/matrix-test.c
> > >
> > > and note UNIT_TEST and MATRIX_TEST_EXPORT that give the test code
> > > access to otherwise static functions.
> >
> > I agree this looks like a better approach.  I wonder if the define
> > could be named differently to more clearly indicate that the
> > function is normally static?  So maybe like WL_STATIC_TESTABLE or
> > some such?
> >
> > Bryce