lmi
[Top][All Lists]
Advanced

[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.


reply via email to

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