[OE-core] [PATCH 2/8] zlib: Add ptest

[Richard Purdie]

On Fri, 2013-02-22 at 16:56 +0100, Björn Stenberg wrote:
> Richard Purdie wrote:
> > > +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.
> 
> Will it?

It will.

>  The intention is to specify that make is only required for running
> zlib-ptest (and only on target). We do a similar RDEPENDS-ptest
> declaration in glib-2.0, adding some tzdata and python packages.

See below.
> 
> I must admit to not building without ptest very often, but I was under
> the impression this works as intended.

I'm not saying it won't work. What it will do is increase build time,
probably significantly, particularly if we do this a lot. This will not
be acceptable to some.

> > I also wonder if the make dependency itself isn't best left against the
> > main ptest-runner script itself rather and each ptest package.
> 
> While make is used by many test suites and could be added to
> ptest-runnner to reduce clutter in other recipes, I think it is the
> wrong thing to do. You don't have to install ptest-runner to run
> ptests, it is merely a convenience script that makes it easier to run
> all of them at once.
> 
> Also, make is not the only package required by test suites. For
> example the gcc-runtime test suite I'll be submitting soon depends on
> dejagnu (which depends on expect, which depends on tcl). And others
> still depend on perl or other largeish packages.

The issue is that on most system images other than tiny ones, we
probably end up triggering perl/python to build. Most devices don't end
up with make. If we do go this route (and I'm not sure we have any
choice), we need to ensure that the dependencies don't hurt people who
don't want ptest and to try and minimise the performance impact. We at
least need to be aware it will hurt build performance.

Cheers,

Richard