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

[Thomas Petazzoni <thomas.petazzoni@free-electrons.com>]

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