lmi
[Top][All Lists]
Advanced

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

Re: [lmi] Please review Makefile.am changes


From: Greg Chicares
Subject: Re: [lmi] Please review Makefile.am changes
Date: Tue, 27 Feb 2018 13:16:46 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2

On 2018-02-27 01:31, Vadim Zeitlin wrote:
> On Tue, 27 Feb 2018 00:14:49 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> The changes I just pushed are intended to mirror the objects used in
> GC> 'objects.make' for two unit tests.
> GC> 
> GC> input_test: it looks like Makefile.am was building the "antediluvian"
> GC> fork, which is not at all what we use in production.
> 
>  I admit I have no idea why was it doing this, all I can say is that the
> file antediluvian_stubs.cpp was added by you to both this file and
> objects.make in the commit 65e27f76247fa4d086915ad14aad910a4493bb68. In any
> case, I certainly don't have any objections to this change.

The problem is that in commit c80f750bb67824828ef0019bd969ce0b6e670a12:

    Use production branch for class Input's unit test
    
    Formerly, this test used the antediluvian branch. It is more useful to
    test the production branch.

...I changed 'objects.make' only and omitted to change 'Makefile.am'.

> GC> rate_table_test: perhaps the earlier version was equivalent, but the
> GC> proposed revision seems more consistent with other unit tests in that
> GC> it lists all objects instead of linking a library.
> 
>  I agree that consistency between these files is important but I'd just
> like to say that, ideally, I'd avoid compiling the same files over and over
> again as part of dozens of tests and would use a library containing them
> instead. It might be marginally simpler to list the files in each test
> (although I'm not even sure why is this the case, to be honest), but the
> compilation times, and the disk space taken by the files, does add up...
The '*.make' files implement standalone unit tests in the most natural
way--as standalone programs produced by linking the required objects:
only those required, and no others. For example:

assert_lmi_test$(EXEEXT): \
  $(common_test_objects) \
  assert_lmi_test.o \

(where these:
  common_test_objects := alert.o alert_cli.o fenv_lmi.o getopt.o license.o
are needed by the framework that all unit tests share:
  all unit tests include "test_tools.hpp", which includes:
    #   include "cpp_main.cpp"
    #   include "test_main.cpp"
  cpp_main   requires getopt.o and license.o
  test_main  requires fenv_lmi.o
  fenv_lmi.o requires alert.o and alert_cli.o
so all these files are required for all unit tests).

The motivation is not to make the unit-test targets simpler to write.
(It would be simpler to write them so that they depend on every object
that can be built for lmi, whether needed or not--either as a variable
like $(common_test_objects) or a list of libraries.) The motivation is
actually to make each unit-test target rebuild as fast as possible,
because I often do something like this:

$make $coefficiency unit_tests unit_test_targets=numeric_io_test.exe 2>&1 |less 
-S

repeatedly when testing different implementations (e.g., yesterday
for various versions of simplify_floating_point()). If I change only
one file ('numeric_io_traits.hpp' in this case), I must wait for all
objects that depend on it to recompile, but I don't want to wait for
all libraries that use all such objects to relink. Thus, this approach
speeds up the {edit->compile->link->run}->repeat workflow and makes me
more productive--and that's a priceless advantage.

Because I can write my own makefiles to do exactly what I want, I can
build all objects in the same directory, which is the most natural
way, and the speediest, as I rarely need to recompile reused files
like 'license.o': instead, rebuilding a unit test does the least
amount of work possible. That's what 'make' was designed to do.

Autotools seem to work otherwise, removing my liberty to optimize
my workflow for efficiency by mandating a separate subdirectory for
each unit test IIRC. That's simply broken IMO. I suppose tools like
ccache might be used to alleviate the consequences of this breakage.
I find it simpler just to avoid autotools in general.

Given that we have two build systems to maintain, it's best to
maintain them in parallel: that's not easy, and mistakes will be
made (as in commit c80f750b above), but such mistakes can also be
found and corrected by textual comparison--which becomes difficult
or impossible if the way they express dependencies differs, e.g.
because autotools unit tests use libraries instead of object lists.
This cries out for automation, to save labor and guarantee correct
maintenance; maybe it's time to reconsider this:

http://lists.nongnu.org/archive/html/lmi/2006-01/msg00035.html
| I took a copy of 'Makefile.am' and removed everything that simply duplicated
| 'objects.make'. Only thirty lines remained out of the original 757, so the
| two files are somewhere between 90 and 100% equivalent. Compare:
...
| Instead of maintaining these two files in parallel, I think our time would
| be better spent on finding a way to make them conformable, so that only one
| would take any real work to maintain. For example:
[...concrete proposal...]



reply via email to

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