[Buildroot] [PATCH] uclibc-test: new package

[Buildroot] [PATCH] uclibc-test: new package

[Waldemar Brodkorb]

The next release of uClibc-ng will have the test suite removed.
Add a separate package for a chance of testing it before the next release.
The test suite can be used to do reference testing on a GNU libc
system.

Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
---
 package/Config.in                  |  1 +
 package/uclibc-test/Config.in      |  7 ++++++
 package/uclibc-test/uclibc-test.mk | 45 ++++++++++++++++++++++++++++++++++++++
 3 files changed, 53 insertions(+)
 create mode 100644 package/uclibc-test/Config.in
 create mode 100644 package/uclibc-test/uclibc-test.mk

diff --git a/package/Config.in b/package/Config.in
index 9ed296f..6451f58 100644
--- a/package/Config.in
+++ b/package/Config.in
@@ -114,6 +114,7 @@ menu "Debugging, profiling and benchmark"
 	source "package/tinymembench/Config.in"
 	source "package/trace-cmd/Config.in"
 	source "package/trinity/Config.in"
+	source "package/uclibc-test/Config.in"
 	source "package/valgrind/Config.in"
 	source "package/whetstone/Config.in"
 endmenu
diff --git a/package/uclibc-test/Config.in b/package/uclibc-test/Config.in
new file mode 100644
index 0000000..6e73701
--- /dev/null
+++ b/package/uclibc-test/Config.in
@@ -0,0 +1,7 @@
+config BR2_PACKAGE_UCLIBC_TEST
+	bool "uclibc-test"
+	help
+	  Test suite for uClibc.
+	  Can also be used for GNU libc.
+
+	  http://www.uclibc-ng.org
diff --git a/package/uclibc-test/uclibc-test.mk b/package/uclibc-test/uclibc-test.mk
new file mode 100644
index 0000000..1a3d651
--- /dev/null
+++ b/package/uclibc-test/uclibc-test.mk
@@ -0,0 +1,45 @@
+################################################################################
+#
+# uclibc-test
+#
+################################################################################
+
+UCLIBC_TEST_VERSION = 094224b6b6a11ae8cb5b7d47e62e25235704fe0b
+UCLIBC_TEST_SITE = git://uclibc-ng.org/git/uclibc-ng-test
+UCLIBC_TEST_LICENSE = LGPLv2.1+
+UCLIBC_TEST_LICENSE_FILES = COPYING.LIB
+
+ifeq ($(BR2_TOOLCHAIN_BUILDROOT_WCHAR),)
+UCLIBC_TEST_MAKE_ENV += NO_WCHAR=1
+endif
+ifeq ($(BR2_TOOLCHAIN_BUILDROOT_LOCALE),)
+UCLIBC_TEST_MAKE_ENV += NO_LOCALE=1
+endif
+ifeq ($(BR2_PTHREADS_NONE),y)
+UCLIBC_TEST_MAKE_ENV += NO_TLS=1 NO_THREADS=1
+endif
+ifeq ($(BR2_PTHREADS_OLD),y)
+UCLIBC_TEST_MAKE_ENV += NO_TLS=1 NO_NPTL=1
+endif
+ifeq ($(BR2_STATIC_LIBS),y)
+UCLIBC_TEST_MAKE_ENV += NO_TLS=1 NO_NPTL=1 NO_DL=1
+endif
+
+define UCLIBC_TEST_BUILD_CMDS
+	$(TARGET_MAKE_ENV) $(UCLIBC_TEST_MAKE_ENV) $(MAKE) -C $(@D) \
+		CC="$(TARGET_CC)" \
+		UCLIBC_EXTRA_CFLAGS="$(TARGET_CFLAGS)" \
+		test_compile
+	$(TARGET_MAKE_ENV) $(UCLIBC_TEST_MAKE_ENV) $(MAKE) -C $(@D) \
+		CC="$(TARGET_CC)" \
+		UCLIBC_EXTRA_CFLAGS="$(TARGET_CFLAGS)" \
+		test_gen
+endef
+
+define UCLIBC_TEST_INSTALL_TARGET_CMDS
+	mkdir -p $(TARGET_DIR)/root/uClibc
+	cp -rdpf $(@D)/test $(TARGET_DIR)/root/uClibc
+	find $(TARGET_DIR)/root/uClibc -name \*.o -exec rm {} \;
+endef
+
+$(eval $(generic-package))
-- 
2.1.4

[Buildroot] [PATCH] uclibc-test: new package

[Arnout Vandecappelle]

On 05-11-16 11:53, Waldemar Brodkorb wrote:
> The next release of uClibc-ng will have the test suite removed.
> Add a separate package for a chance of testing it before the next release.
> The test suite can be used to do reference testing on a GNU libc
> system.
> 
> Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
> ---
>  package/Config.in                  |  1 +
>  package/uclibc-test/Config.in      |  7 ++++++
>  package/uclibc-test/uclibc-test.mk | 45 ++++++++++++++++++++++++++++++++++++++
>  3 files changed, 53 insertions(+)
>  create mode 100644 package/uclibc-test/Config.in
>  create mode 100644 package/uclibc-test/uclibc-test.mk
> 
> diff --git a/package/Config.in b/package/Config.in
> index 9ed296f..6451f58 100644
> --- a/package/Config.in
> +++ b/package/Config.in
> @@ -114,6 +114,7 @@ menu "Debugging, profiling and benchmark"
>  	source "package/tinymembench/Config.in"
>  	source "package/trace-cmd/Config.in"
>  	source "package/trinity/Config.in"
> +	source "package/uclibc-test/Config.in"
>  	source "package/valgrind/Config.in"
>  	source "package/whetstone/Config.in"
>  endmenu
> diff --git a/package/uclibc-test/Config.in b/package/uclibc-test/Config.in
> new file mode 100644
> index 0000000..6e73701
> --- /dev/null
> +++ b/package/uclibc-test/Config.in
> @@ -0,0 +1,7 @@
> +config BR2_PACKAGE_UCLIBC_TEST
> +	bool "uclibc-test"
> +	help
> +	  Test suite for uClibc.
> +	  Can also be used for GNU libc.

 Not musl? If not musl, probably better add a dependency on !MUSL. If musl is
OK, mention it here as well.

 BTW, test-double seems not to build with glibc (but I was using a very unclean
environment so maybe I did something wrong).

> +
> +	  http://www.uclibc-ng.org
> diff --git a/package/uclibc-test/uclibc-test.mk b/package/uclibc-test/uclibc-test.mk
> new file mode 100644
> index 0000000..1a3d651
> --- /dev/null
> +++ b/package/uclibc-test/uclibc-test.mk
> @@ -0,0 +1,45 @@
> +################################################################################
> +#
> +# uclibc-test
> +#
> +################################################################################
> +
> +UCLIBC_TEST_VERSION = 094224b6b6a11ae8cb5b7d47e62e25235704fe0b
> +UCLIBC_TEST_SITE = git://uclibc-ng.org/git/uclibc-ng-test

 Why not call the package uclibc-ng-test? Are you still hoping to merge back
with uClibc? :-)

> +UCLIBC_TEST_LICENSE = LGPLv2.1+
> +UCLIBC_TEST_LICENSE_FILES = COPYING.LIB
> +
> +ifeq ($(BR2_TOOLCHAIN_BUILDROOT_WCHAR),)

 I guess this should be BR2_USE_WCHAR?

> +UCLIBC_TEST_MAKE_ENV += NO_WCHAR=1
> +endif
> +ifeq ($(BR2_TOOLCHAIN_BUILDROOT_LOCALE),)

 BR2_ENABLE_LOCALE

> +UCLIBC_TEST_MAKE_ENV += NO_LOCALE=1
> +endif
> +ifeq ($(BR2_PTHREADS_NONE),y)

 BR2_TOOLCHAIN_HAS_THREADS

> +UCLIBC_TEST_MAKE_ENV += NO_TLS=1 NO_THREADS=1
> +endif
> +ifeq ($(BR2_PTHREADS_OLD),y)

 BR2_TOOLCHAIN_HAS_THREADS_NPTL

 Also make it an else ifeq I think.

> +UCLIBC_TEST_MAKE_ENV += NO_TLS=1 NO_NPTL=1
> +endif
> +ifeq ($(BR2_STATIC_LIBS),y)
> +UCLIBC_TEST_MAKE_ENV += NO_TLS=1 NO_NPTL=1 NO_DL=1

 Static implies NO_TLS and NO_NPTL? That warrants a comment...

> +endif
> +
> +define UCLIBC_TEST_BUILD_CMDS
> +	$(TARGET_MAKE_ENV) $(UCLIBC_TEST_MAKE_ENV) $(MAKE) -C $(@D) \
> +		CC="$(TARGET_CC)" \
> +		UCLIBC_EXTRA_CFLAGS="$(TARGET_CFLAGS)" \
> +		test_compile
> +	$(TARGET_MAKE_ENV) $(UCLIBC_TEST_MAKE_ENV) $(MAKE) -C $(@D) \
> +		CC="$(TARGET_CC)" \
> +		UCLIBC_EXTRA_CFLAGS="$(TARGET_CFLAGS)" \
> +		test_gen

 Can't this be done in one make invocation 'make ... test_compile test_gen'? Or
is there a parallel build issue?

> +endef
> +
> +define UCLIBC_TEST_INSTALL_TARGET_CMDS
> +	mkdir -p $(TARGET_DIR)/root/uClibc

 I don't like this location. ltp-testsuite installs in /usr/lib/ltp-testsuite,
so I'd propose /usr/lib/uclibc-ng-test

> +	cp -rdpf $(@D)/test $(TARGET_DIR)/root/uClibc
> +	find $(TARGET_DIR)/root/uClibc -name \*.o -exec rm {} \;

 This I don't like at all, first copying everything and then removing the object
files (what about all the source files BTW?).

 Instead, how about something like:

rsync -a --exclude '*.[cho]'

?

 Or even better, add an install target to the package :-)


 Regards,
 Arnout

> +endef
> +
> +$(eval $(generic-package))
> 

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] [PATCH] uclibc-test: new package

[Waldemar Brodkorb]

Hi Arnout,
Arnout Vandecappelle wrote,

> > +	  Can also be used for GNU libc.
> 
>  Not musl? If not musl, probably better add a dependency on !MUSL. If musl is
> OK, mention it here as well.

I fixed compile for musl, so I will update the comment.
 
>  BTW, test-double seems not to build with glibc (but I was using a very unclean
> environment so maybe I did something wrong).

No, there where some CFLAGS missing, I fixed it.
 
> > +UCLIBC_TEST_VERSION = 094224b6b6a11ae8cb5b7d47e62e25235704fe0b
> > +UCLIBC_TEST_SITE = git://uclibc-ng.org/git/uclibc-ng-test
> 
>  Why not call the package uclibc-ng-test? Are you still hoping to merge back
> with uClibc? :-)

No. :)
I just thought it might better align with package/uclibc.
What other think? How should the package be named?
 
> > +UCLIBC_TEST_LICENSE = LGPLv2.1+
> > +UCLIBC_TEST_LICENSE_FILES = COPYING.LIB
> > +
> > +ifeq ($(BR2_TOOLCHAIN_BUILDROOT_WCHAR),)
> 
>  I guess this should be BR2_USE_WCHAR?

Not sure. When do I should use BR2_TOOLCHAIN_BUILDROOT_* and when
BR2_USE_*?
 
> > +ifeq ($(BR2_STATIC_LIBS),y)
> > +UCLIBC_TEST_MAKE_ENV += NO_TLS=1 NO_NPTL=1 NO_DL=1
> 
>  Static implies NO_TLS and NO_NPTL? That warrants a comment...

Most of the TLS and NPTL tests use dlopen.
 
> > +endif
> > +
> > +define UCLIBC_TEST_BUILD_CMDS
> > +	$(TARGET_MAKE_ENV) $(UCLIBC_TEST_MAKE_ENV) $(MAKE) -C $(@D) \
> > +		CC="$(TARGET_CC)" \
> > +		UCLIBC_EXTRA_CFLAGS="$(TARGET_CFLAGS)" \
> > +		test_compile
> > +	$(TARGET_MAKE_ENV) $(UCLIBC_TEST_MAKE_ENV) $(MAKE) -C $(@D) \
> > +		CC="$(TARGET_CC)" \
> > +		UCLIBC_EXTRA_CFLAGS="$(TARGET_CFLAGS)" \
> > +		test_gen
> 
>  Can't this be done in one make invocation 'make ... test_compile test_gen'? Or
> is there a parallel build issue?

Not exactly an issue. It will generate the needed meta data, the
order of test case execution will be random and not always the same
order. If this is not important, I can combine this.
 
> > +endef
> > +
> > +define UCLIBC_TEST_INSTALL_TARGET_CMDS
> > +	mkdir -p $(TARGET_DIR)/root/uClibc
> 
>  I don't like this location. ltp-testsuite installs in /usr/lib/ltp-testsuite,
> so I'd propose /usr/lib/uclibc-ng-test

Okay.
 
> > +	cp -rdpf $(@D)/test $(TARGET_DIR)/root/uClibc
> > +	find $(TARGET_DIR)/root/uClibc -name \*.o -exec rm {} \;
> 
>  This I don't like at all, first copying everything and then removing the object
> files (what about all the source files BTW?).
> 
>  Instead, how about something like:
> 
> rsync -a --exclude '*.[cho]'
> 
> ?
> 
>  Or even better, add an install target to the package :-)

I added a install target.

best regards
 Waldemar

[Buildroot] [PATCH] uclibc-test: new package

[Thomas Petazzoni]

Hello,

On Sat, 12 Nov 2016 20:23:25 +0100, Waldemar Brodkorb wrote:

> >  Why not call the package uclibc-ng-test? Are you still hoping to merge back
> > with uClibc? :-)  
> 
> No. :)
> I just thought it might better align with package/uclibc.
> What other think? How should the package be named?

We always prefer the upstream name of the package, i.e uclibc-ng-test
in this case. "uclibc" is kind of a special case: it used to be the
original upstream name, until it went dead and you forked it. But in
all other cases, using the upstream name is preferred.

> Not sure. When do I should use BR2_TOOLCHAIN_BUILDROOT_* and when
> BR2_USE_*?

Easy: the BR2_TOOLCHAIN_BUILDROOT_* options are specific to the
internal toolchain backend, they have no meaning if you use an external
toolchain or even for many of them if you use glibc or musl with the
internal toolchain backend. They are visible options that allow the
user to tell whether he wants this feature or not in the toolchain to
be built by Buildroot.

On the other hand, BR2_USE_WCHAR, BR2_TOOLCHAIN_HAS_THREADS, etc. are
blind options that tell packages which features are provided by the
toolchain. They always exist, regardless of whether you're using the
internal or external toolchain backend, and regardless of the C library
you're using.

> >  Static implies NO_TLS and NO_NPTL? That warrants a comment...  
> 
> Most of the TLS and NPTL tests use dlopen.

Needs a comment, as Arnout said.

> >  Can't this be done in one make invocation 'make ... test_compile test_gen'? Or
> > is there a parallel build issue?  
> 
> Not exactly an issue. It will generate the needed meta data, the
> order of test case execution will be random and not always the same
> order. If this is not important, I can combine this.

I think having the test execution in predictable order is a nice
feature of test suites, no?

Thanks,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com