<[EMAIL PROTECTED]>Ralf Wildenhues writes:
>Hi Tom,
Hi!
>* tom fogal wrote on Mon, Mar 27, 2006 at 11:17:51PM CEST:
<snip>
>> 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:
>
>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
subdirectories.
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/Makefile.am, append "test" to a variable I have
>> defined.
>
>In Makefile.am, append "tests/test" instead.
>
>> 3) in /tests/Makefile.am, add a "test_SOURCES=test.cpp" line.
>
>In Makefile.am, 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.
<snip>
>> 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.
>
>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:
<snip>
>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 Makefile.am
>SUBDIRS = src tests
>$ cat src/Makefile.am
>noinst_LIBRARIES = libeverything.a libsomething.a
>libeverything_a_SOURCES = s1.c s2.c
>libsomething_a_SOURCES = s2.c
>$ cat tests/Makefile.am
>TESTS = $(check_PROGRAMS)
>check_PROGRAMS = a$(EXEEXT) b$(EXEEXT) c$(EXEEXT)
>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 configure.ac, 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
generates
test1_SOURCES=../src/abc.cpp ../src/x.cpp
test2_SOURCES=../src/blah.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.
Thanks!
-tom
