[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: test setup advice

From: tom fogal
Subject: Re: test setup advice
Date: Tue, 28 Mar 2006 22:20:18 -0500

 <address@hidden>Ralf Wildenhues writes:
>Hi Tom,


>* tom fogal wrote on Mon, Mar 27, 2006 at 11:17:51PM CEST:
>> My /tests directory then uses that same `everything' library to link
>> all of the test programs against.  However the build trees for /src and
>> /tests are separate; the toplevel uses SUBDIRS to descend
>> into each of them.  The advantage of this whole setup is that adding a
>> test is very simple:
>Just FYI: if you used a non-recursive setup, all you'd need to change
>would be (don't forget subdir-objects!):

Well... I sort-of did ;).  As it turns out /src is a large tree which
is all built non-recursively, and /tests similarly (although the latter
isn't as large).  Its only recursive to jump into those two
I'm not exactly sure why I did things that way though, and now that you
bring it to my attention I can't think of a good reason why I would
even want those two stages of the build separated out like they are.

>>     1) write the test into e.g. "test.cpp"
>>     2) in /tests/, append "test" to a variable I have
>>        defined.
>In, append "tests/test" instead.
>>     3) in /tests/, add a "test_SOURCES=test.cpp" line.
>In, add a "tests_tests_SOURCES = test.cpp" line.
>> Unfortunately this lacks a lot of dependency information.  My new
>> "test" depends on the `everything' library, which is correct, but it
>> *really* only depends on one or two files from my /src tree.
>So I assume you have "LDADD = ../src/libeverything.a".

Yes, this is correct.

>> The solution, of course, is to drop the `everything' library and
>> explicitly code in the dependencies on particular files for every
>> individual test.  This is going to cause /tests/ to become
>> very large and intricate though, and thus I believe adding a test will
>> be a very error prone activity.
>You could change incrementally, you could use more than one convenience
>library to have more fine-grained control, and you could even list
>sources explicitly.
>Let me show you an example with C code:
>Here, by default, all programs will be linked against libeverything.
>That is overridden for tests/b and tests/c: the former only uses s2.c,
>while the latter only uses libsomething.
>The respective nonrecursive setup looks like this:
>$ cat
>SUBDIRS = src tests
>$ cat src/
>noinst_LIBRARIES = libeverything.a libsomething.a
>libeverything_a_SOURCES = s1.c s2.c
>libsomething_a_SOURCES = s2.c
>$ cat tests/
>TESTS = $(check_PROGRAMS)
>a_SOURCES = a.c
>b_SOURCES = b.c ../src/s1.c
>c_SOURCES = c.c
>LDADD = ../src/libeverything.a
>b_LDADD =
>c_LDADD = ../src/libsomething.a

Hrm, the multiple libraries idea looks like a fairly good compromise
between having each of {a,b,c,...,zz}_SOURCES list its set of dependant
source files and my current `solution' (listing practically nothing).

>(and obviously you need to adjust the list of files in AC_CONFIG_FILES
>in, too).  Does that help?

Its an order of magnitude better than what I've got now certainly.
What I'd really like to see is a program which parses tests/*cpp and
   test1_SOURCES=../src/abc.cpp ../src/x.cpp
        test3_SOURCES=(large 30 line list perhaps, for huge test)
Which I could then include into the appropriate part of my
(auto)Makefile.  Doing the above is really ideal, I just think doing it
manually will cause me to screw it up constantly.

Multiple libraries, perhaps one per program module, seems like a
reasonable alternative thats human-maintainable and gets most of the
benefits of doing the full source listings.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]