I'm looking for advice on how to structure a build system using
automake.
I'm writing a C++ project which I currently have just under 30
automake-based tests (e.g. check_PROGRAMS, TESTS) created. The
structure of my build system is that all of my source files for the
program (under /src) build a `noinst' static library. Then I compile
the file with main() and link in this `everything' library.
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 Makefile.am uses SUBDIRS to descend
into each of them. The advantage of this whole setup is that adding a
test is very simple:
1) write the test into e.g. "test.cpp"
2) in /tests/Makefile.am, append "test" to a variable I have
defined.
3) in /tests/Makefile.am, add a "test_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. The
upshot is that if I change anything from my /src tree, all of my tests
are recompiled. This wouldn't be such a big deal, but C++ is
relatively slow to compile / link. When I get 80 or so tests (which
seems like it will be quite reasonable), I imagine I won't even want to
bother running 'make check' anymore, and this will defeat the whole
purpose of my unit testing.
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/Makefile.am to become
very large and intricate though, and thus I believe adding a test will
be a very error prone activity. Fortunately I'm working alone on this
project, but sometimes I work with those who are less knowledgeable
about automake, and in those cases I imagine it will be more work than
its worth to maintain the dependencies in /tests/Makefile.am.
Have others run into this problem? Is explicitly listing the
dependencies of every check_PROGRAM really the only solution? Are
there any tools / guides you have found useful in managing a large
suite of tests? Maybe I should be switching to a different test
framework?
Thanks for any solutions / ideas / comments.
-tom
