Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Waldemar Brodkorb <wbx@openadk.org>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH] uclibc-test: new package
Date: Sat, 12 Nov 2016 20:23:25 +0100	[thread overview]
Message-ID: <20161112192324.GN27313@waldemar-brodkorb.de> (raw)
In-Reply-To: <bc4b5500-9bc2-90e3-975e-2f527d157e33@mind.be>

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

  reply	other threads:[~2016-11-12 19:23 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-05 10:53 [Buildroot] [PATCH] uclibc-test: new package Waldemar Brodkorb
2016-11-05 21:16 ` Arnout Vandecappelle
2016-11-12 19:23   ` Waldemar Brodkorb [this message]
2016-11-12 20:01     ` Thomas Petazzoni

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20161112192324.GN27313@waldemar-brodkorb.de \
    --to=wbx@openadk.org \
    --cc=buildroot@busybox.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox