From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: "Björn Stenberg" <bjst@enea.com>
Cc: Anders Roxell <anders.roxell@enea.com>,
openembedded-core@lists.openembedded.org
Subject: Re: [PATCH 2/8] zlib: Add ptest
Date: Fri, 22 Feb 2013 09:39:38 -0800 [thread overview]
Message-ID: <1361554778.25338.31.camel@ted> (raw)
In-Reply-To: <20130222155605.GI55106@sestofb10.enea.se>
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
next prev parent reply other threads:[~2013-02-22 17:56 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-19 13:13 [PATCH 0/8] Ptest additions Björn Stenberg
2013-02-19 13:13 ` [PATCH 1/8] busybox: Add ptest Björn Stenberg
2013-02-19 14:04 ` Bernhard Reutner-Fischer
2013-02-20 14:52 ` [PATCH 1/8 v2] " Björn Stenberg
2013-02-19 13:13 ` [PATCH 2/8] zlib: " Björn Stenberg
2013-02-22 14:02 ` Richard Purdie
2013-02-22 15:56 ` Björn Stenberg
2013-02-22 17:39 ` Richard Purdie [this message]
2013-02-19 13:13 ` [PATCH 3/8] udev: " Björn Stenberg
2013-02-21 6:55 ` Saul Wold
2013-02-19 13:14 ` [PATCH 4/8] acl: " Björn Stenberg
2013-02-22 13:59 ` Richard Purdie
2013-02-19 13:14 ` [PATCH 5/8] bzip2: " Björn Stenberg
2013-02-19 13:14 ` [PATCH 6/8] openssh: " Björn Stenberg
2013-02-19 13:14 ` [PATCH 7/8] openssl: " Björn Stenberg
2013-02-22 14:05 ` Richard Purdie
2013-02-19 13:14 ` [PATCH 8/8] ptest: Add missed .debug path Björn Stenberg
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=1361554778.25338.31.camel@ted \
--to=richard.purdie@linuxfoundation.org \
--cc=anders.roxell@enea.com \
--cc=bjst@enea.com \
--cc=openembedded-core@lists.openembedded.org \
/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