libgcrypt parallel tests automake>=1.13 issue
Closed, ResolvedPublic

Description

issue with parallel tests of automake, a fix is to disable it for now.

can you please seek the proper solution?

thanks!

Details

alonbl set External Link to https://bugs.gentoo.org/show_bug.cgi?id=498718.
alonbl set Version to 1.6.0.
alonbl added a subscriber: alonbl.
werner closed this task as Resolved.Jan 27 2014, 11:36 AM
werner claimed this task.
werner added a project: Won't Fix.

Thist patch does not work because the serial-tests flag is not supported by
older automake versions. The problem has already been discussed at the mailing
lists. See README.GIT on how to use a non-broken automake. I still hope the
utomake folks solve the problem by changing the default. Forcing all projects
to use the new and incompatible parallel tests was a very unpleasant behaviour
of them.

why do you close issues so fast?

"""can you please seek the proper solution?"""

means that I ask to fix build to have proper dependencies between tests to allow
serial or parallel execution. this will work in any version.

alonbl reopened this task as Open.Jan 27 2014, 11:40 AM

Because that automake version is not supported. automake is a maintainer tool
and not a build dependency. If Gentoo has its own policy they are on their own

  • it is free software. The tarball release does not have this problem. Or am I

wrong? GIT is developer only and definitely not a release.

werner closed this task as Resolved.Jan 28 2014, 3:28 PM
alonbl reopened this task as Open.Jan 28 2014, 11:15 PM

We patch your sources mainly because[1], I will be happy to stop autoreconf your
packages, but cannot do this until this and other issues are resolved.

[1]
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-libs/libgcrypt/files/libgcrypt-1.5.0-uscore.patch?revision=1.1&view=markup

OK, someone already tried to solve it at your side:

tests/Makefile.am

  1. Force sequential run of some tests. bench-slope.log: benchmark.log hashtest-256g.log: bench-slope.log

However, from automake manual:

In order to guarantee an ordering between tests even with make -jN, dependencies
between the corresponding .log files may be specified through usual make
dependencies. For example, the following snippet lets the test named
foo-execute.test depend upon completion of the test foo-compile.test:

TESTS = foo-compile.test foo-execute.test
foo-execute.log: foo-compile.log

Please note that this ordering ignores the results of required tests, thus the
test foo-execute.test is run even if the test foo-compile.test failed or was
skipped beforehand. Further, please note that specifying such dependencies
currently works only for tests that end in one of the suffixes listed in
TEST_EXTENSIONS.

Removing the above makes all works in parallel without specific order, which is
nice... unsure why the above was added when there is no real dependency, and
prior to automake-1.13 there was no parallel anyway.

That was added because we have it in master.

Again: If you do not use the tarball release do not expect that pacthes will be
included. You should never do autoreconf.

werner closed this task as Resolved.Jan 29 2014, 8:26 AM

That was added because we have it in master.

Have 'it'? I see it in the tarball of 1.6.

Again: If you do not use the tarball release do not expect that pacthes will

be included. You should never do autoreconf.

We do use the tarball release, and we must patch it to resolve issues you do not
handle as I presented in previous comment.

alonbl reopened this task as Open.Jan 29 2014, 10:19 AM

I am confused:

Do you say that you have problems to build the tarball release? In that case I
can replicate the problem. FWIW, the 1.6.1 release has been build with automake
1.11 and I am pretty sure that this was also the case for 1.6.0.
From the top Makefile.in:

Makefile.in generated by automake 1.11.6 from Makefile.am.

So, why do you need autoreconf to fix a problem with parallel tests? automake
1.11 does not generate such test rules.

the tarball is OK, however, we must patch the autoconf[1], so we also use the
automake installed at user site which may be newer than 1.13.

it seems that this expression has no effect to 1.13 and damage the 1.14...

bench-slope.log: benchmark.log
hashtest-256g.log: bench-slope.log

you can close this issue, but know that it does exist in newer versions of
automake. if there is no real need for the above statements then removing them
resolves the issue.

[1]
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-libs/libgcrypt/files/libgcrypt-1.5.0-uscore.patch?revision=1.1&view=markup

A user shall not use automake to build libgrypt.

I am very well aware of all the problems with newer automake versions. I try to
eventually mitigate the problems and the extra rules we have in some projects
might be helpful but a proper solution for automake would be to reverse the
default tests method to serial-tests. There are only a few projects with lots
of regression tests which benefit from the new default - those could easily
switch on parallel-tests. But I have seen no signs that they will revert it.

Eventually we need to add our own test driver - IIRC, recent automakes allow to
enable a custom test driver while still having build support by automake.

gniibe added a subscriber: gniibe.May 7 2015, 4:04 AM

In 1.6.3, libgcrypt now work with automake >= 1.14.

See the commit: c123e313e90a6ffb14c9be3ddaab3ad44a44f2b6

gniibe closed this task as Resolved.