[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lmi] Common test objects are too common
From: |
Greg Chicares |
Subject: |
Re: [lmi] Common test objects are too common |
Date: |
Sun, 21 Mar 2021 14:28:29 +0000 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0 |
On 3/21/21 12:40 PM, Vadim Zeitlin wrote:
> On Sun, 7 Mar 2021 13:30:01 +0100 I wrote:
>
>> We currently have 72 tests using common_test_objects variable in
>> objects.make. This means that 6 files included in this variable are
>> compiled at least 432 times
[...for 'Makefile.am'; however...]
> this is not at all the case for objects.make, which builds
> these objects just once and then reuses them in all the tests.
Exactly. I think we discussed this many years ago, perhaps from
a different angle--e.g., these messages:
https://lists.nongnu.org/archive/html/lmi/2006-01/msg00000.html
https://lists.nongnu.org/archive/html/lmi/2006-01/msg00007.html
and the thread starting here:
https://lists.nongnu.org/archive/html/lmi/2006-01/msg00027.html
IIRC, the usual autotools method is to create a subdirectory for
each unit-test TU, and build that TU and all other object files
it requires in that subdirectory.
OTOH, for the default build_type, the lmi makefiles use a common
directory for all objects--and avoid using shared-library
decorations, so that an object file that was already built for
inclusion in a shared library can be linked statically in a
unit test.
An alternative would be to build a shared library that contains
all "common" code (perhaps the present 'liblmi.so'), and link
each unit test to that library. Very often, I develop new code
in parallel with a corresponding unit test. This alternative
would require relinking the common '.so' at each iteration
(because it would contain the code being tested), but then
linking the unit-test binary itself would be faster; I suspect
that linking all required objects into the unit-test binary
takes less time overall.
> [...] I would still like to submit a patch with some changes required
> to fix the problem with autotools-based makefiles
Sure.
Tangentially, I'd like to propose a naming change. Adding
an "et_vector" unit test meant adding this to 'objects.make':
et_vector_test \
et_vector_test$(EXEEXT): \
$(common_test_objects) \
et_vector_test.o \
timer.o \
and this to 'Makefile.am':
test_et_vector \
test_et_vector_SOURCES = \
$(common_test_objects) \
et_vector_test.cpp \
timer.cpp
test_et_vector_CXXFLAGS = $(AM_CXXFLAGS)
Could we change "test_et_vector" to "et_vector_test"?
Then the name of the '.cpp' file would be the same as
the name of the test, which would be easier for me
because then I could just search and replace a single
string which is unambiguously associated with this
test.