Re: [PATCH 2/8] zlib: Add ptest

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Tue, 2013-02-19 at 14:13 +0100, Björn Stenberg wrote:
> From: Anders Roxell <anders.roxell@enea.com>
> 
> Signed-off-by: Björn Stenberg <bjst@enea.com>
> Signed-off-by: Anders Roxell <anders.roxell@enea.com>
> ---
>  .../zlib/zlib-1.2.7/Makefile-runtests.patch        |   38 ++++++++++++++++++++
>  meta/recipes-core/zlib/zlib-1.2.7/run-ptest        |    7 ++++
>  meta/recipes-core/zlib/zlib_1.2.7.bb               |   22 +++++++++++
>  3 files changed, 67 insertions(+), 0 deletions(-)
>  create mode 100644 meta/recipes-core/zlib/zlib-1.2.7/Makefile-runtests.patch
>  create mode 100644 meta/recipes-core/zlib/zlib-1.2.7/run-ptest
> 
> diff --git a/meta/recipes-core/zlib/zlib-1.2.7/Makefile-runtests.patch b/meta/recipes-core/zlib/zlib-1.2.7/Makefile-runtests.patch
> new file mode 100644
> index 0000000..04c55b4
> --- /dev/null
> +++ b/meta/recipes-core/zlib/zlib-1.2.7/Makefile-runtests.patch
> @@ -0,0 +1,38 @@
> +Add 'ptest' target to Makefile, to run tests without checking dependencies.
> +
> +Signed-off-by: Anders Roxell <anders.roxell@enea.com>
> +Upstream-Status: Pending
> +---
> +diff -uNr a/Makefile.in b/Makefile.in
> +--- a/Makefile.in	2012-04-23 07:58:06.000000000 +0200
> ++++ b/Makefile.in	2012-10-24 08:24:19.822544837 +0200
> +@@ -83,6 +83,9 @@
> + test: all teststatic testshared
> + 
> + teststatic: static
> ++	@make runteststatic
> ++
> ++runteststatic:
> + 	@TMPST=`mktemp fooXXXXXX`; \
> + 	if echo hello world | ./minigzip | ./minigzip -d && ./example $$TMPST ; then \
> + 	  echo '		*** zlib test OK ***'; \
> +@@ -92,6 +95,9 @@
> + 	rm -f $$TMPST
> + 
> + testshared: shared
> ++	@make runtestshared
> ++
> ++runtestshared:
> + 	@LD_LIBRARY_PATH=`pwd`:$(LD_LIBRARY_PATH) ; export LD_LIBRARY_PATH; \
> + 	LD_LIBRARYN32_PATH=`pwd`:$(LD_LIBRARYN32_PATH) ; export LD_LIBRARYN32_PATH; \
> + 	DYLD_LIBRARY_PATH=`pwd`:$(DYLD_LIBRARY_PATH) ; export DYLD_LIBRARY_PATH; \
> +@@ -105,6 +111,9 @@
> + 	rm -f $$TMPSH
> + 
> + test64: all64
> ++	@make runtest64
> ++
> ++runtest64:
> + 	@TMP64=`mktemp fooXXXXXX`; \
> + 	if echo hello world | ./minigzip64 | ./minigzip64 -d && ./example64 $$TMP64; then \
> + 	  echo '		*** zlib 64-bit test OK ***'; \
> diff --git a/meta/recipes-core/zlib/zlib-1.2.7/run-ptest b/meta/recipes-core/zlib/zlib-1.2.7/run-ptest
> new file mode 100644
> index 0000000..19d9632
> --- /dev/null
> +++ b/meta/recipes-core/zlib/zlib-1.2.7/run-ptest
> @@ -0,0 +1,7 @@
> +#!/bin/sh
> +FILE=zlib-ptest-$$.log
> +make -k runteststatic runtestshared > $FILE
> +sed -i -r -e 's/^(\s+\*+ (.+?) test OK \*+)/\1\nPASS: \2/' $FILE
> +sed -i -r -e 's/^(\s+\*+ (.+?) test FAILED \*+)/\1\nFAIL: \2/' $FILE
> +cat $FILE
> +rm -f $FILE
> diff --git a/meta/recipes-core/zlib/zlib_1.2.7.bb b/meta/recipes-core/zlib/zlib_1.2.7.bb
> index 803fec3..61380ec 100644
> --- a/meta/recipes-core/zlib/zlib_1.2.7.bb
> +++ b/meta/recipes-core/zlib/zlib_1.2.7.bb
> @@ -8,20 +8,42 @@ LIC_FILES_CHKSUM = "file://zlib.h;beginline=4;endline=23;md5=94d1b5a40dadd127f33
>  
>  SRC_URI = "http://www.zlib.net/${BPN}-${PV}.tar.bz2 \
>             file://remove.ldconfig.call.patch \
> +           file://Makefile-runtests.patch \
> +           file://run-ptest \
>             "
>  SRC_URI[md5sum] = "2ab442d169156f34c379c968f3f482dd"
>  SRC_URI[sha256sum] = "49e2e9658dfb036900da6ea0267a737fa3c4eee6666776d378c79d52e9334934"
>  
> +RDEPENDS_${PN}-ptest += "make"
> +RDEPENDS_${PN}-ptest_virtclass-native = ""
> +RDEPENDS_${PN}-ptest_virtclass-nativesdk = ""

The above scares me. Why? This is going to make packaging of zlib
dependent on the packaging of make, due to the way our packaging works.
This means zlib will force make to get built. I need to confirmation at
this point that if ptest isn't enabled, this dependency isn't used.

I also wonder if the make dependency itself isn't best left against the
main ptest-runner script itself rather and each ptest package.

I'd like to protect build performance a bit if I can help it.

> +FILES_${PN}-dbg += "${PTEST_PATH}/.debug"

Is this needed after the other fix?

Cheers,

Richard