[RFC PATCH 0/4] [PIDNS] Trie and pidns-cache tests

[Ákos Uzonyi]

On Tue, 18 Aug 2020 at 01:44, Dmitry V. Levin <ldv at altlinux.org> wrote:
> On Tue, Aug 18, 2020 at 01:21:18AM +0200, Ákos Uzonyi wrote:
> > On Tue, 18 Aug 2020 at 01:12, Dmitry V. Levin <ldv at altlinux.org> wrote:
> > > On Tue, Aug 18, 2020 at 12:12:17AM +0200, Ákos Uzonyi wrote:
> > > > On Sat, 15 Aug 2020 at 18:27, Dmitry V. Levin <ldv at altlinux.org> wrote:
> > > > > On Sat, Aug 15, 2020 at 06:23:26PM +0200, Ákos Uzonyi wrote:
> > > > > > On Sat, 15 Aug 2020 at 14:41, Dmitry V. Levin <ldv at altlinux.org> wrote:
> > > > > > > On Thu, Aug 13, 2020 at 05:32:38PM +0200, Ákos Uzonyi wrote:
> > > > > > > > is it's OK to add ../trie.c ../trie.h to libtests_a_SOURCES?
> > > > > > >
> > > > > > > I suppose automake should be fine with it.  What's your concern?
> > > > > >
> > > > > > Technically there is no problem, I just worried about including a file
> > > > > > not in tests directory, as it hasn't been done before. But if you say
> > > > > > it's OK, then everything is fine :).
> > > > >
> > > > > The only problem is that it won't be built with coverage support,
> > > > > so it won't be shown in coverage reports.
> > > >
> > > > I found an another problem, github CI errors with:
> > > >
> > > > /usr/bin/ld: i386:x86-64 architecture of input file
> > > > `libtests.a(libtests_a-trie.o)' is incompatible with i386 output
> > >
> > > Interesting.  Could you give a link to the full log?
> >
> > https://github.com/AkosUzonyi/strace/runs/994567416
>
> I see, it just built ../libtests_a-trie.o once and used it several times.
>
> > > However, we are probably not interested in running this test for compat
> > > personalities.  There is a loop in ./bootstrap that creates tests-m32 and
> > > tests-mx32 directories, we could do something there to filter it out.
> >
> > Yes, I was also thinking about doing something in bootstrap. But I
> > think it's easier to add a symlink, and it also solves the coverage
> > support problem.
>
> I agree adding a symlink is much easier way to fix the build, but I don't
> see how it solves the coverage support problem.

Sorry, I was wrong about this coverage thing. However pidns tests
already cover nearly all the lines of trie.c (except trie_free), so
trie test's goal is not to add line coverage, but to test edge cases
of trie.