Re: [RFC] squid-3.6 unit tests

On 08/20/2014 09:16 PM, Amos Jeffries wrote:
> Future versions of autoconf/automake will be auto-enabling their
> subdir-objects feature. This impacts Squid in a few ways, the largest
> being how we perform unit testing.
>
> At present our unit tests link to objects in $(top_srcdir)/src/tests/
> and sometimes from other src/foo/ directories. The current automake will
> build a .o file in the current working directory, but with
> subdir-objects the .o would be built in the src/tests/ etc directory and
> shared between any other units using the base .c file.
> This will naturally cause build failures when the source sub-directory
> has not yet been created by the build process. subdir-objects is not
> automatically creating paths.
>
> I am proposing that:
>
> 1) we reverse the decision to build any unit tests in src/
> subdirectories. Returning to the original design of using top level
> test-suite/ directory to build and run them. This will ensure that all
> necessary .la objects and src/ directories are already existing before
> unit tests get built.
>
> We are already facing some problems from that plan. For example when
> unit tests for src/fs/ need to link against src/http/*.la we currently
> have to build them in src/Makefile.am after all src/*/ sub-directories
> have been recursed and built. Some possible compat/ unit tests are also
> blocked by lib/* not being built at the time.
>
>
> 2) the STUB .cc files are moved from src/tests/. With subdir-objects we can
>
> a) place them in the relevant src/foo/ directory, or
> b) place them in src/stubs/.
>
> With a rename from stub_foo.cc to foo.stub.cc so we can make use of a
> generic automate their build and dist operations from Common.am (in case
> of 2a) or src/stubs/Makefile.am (in case of 2b).

No objections from me. While it would be better to localize unit tests,
our unit tests are apparently not local enough to be easily localized.
In many cases, this is probably due to poor quality of the primary code
(too many dependencies), and will take a while to improve.

> If agreed this would take effect after 3.5 branching.

This is your call, but I am surprised you want to make such a relatively
big (and yet essentially simple) change after branching. I would
recommend to do it before you branch to minimize long-term maintenance
overheads.

Thank you,

Alex.
Received on Fri Aug 22 2014 - 17:41:21 MDT