Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: "Björn Stenberg" <bjst@enea.com>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH 1/4] Add a new distro feature "ptest".
Date: Tue, 04 Dec 2012 16:49:22 +0000	[thread overview]
Message-ID: <1354639762.25268.54.camel@ted> (raw)
In-Reply-To: <20121129155210.GC25784@sestofb10.enea.se>

On Thu, 2012-11-29 at 16:52 +0100, Björn Stenberg wrote:
> Richard Purdie wrote:
> > >  meta/classes/image.bbclass                         |    6 ++-
> > >  meta/classes/packagegroup.bbclass                  |    2 +-
> > >  meta/conf/bitbake.conf                             |   15 ++++++++-
> > 
> > Whilst we're in bootstrapping mode for this work, how about we make
> > these changes a "ptest.bbclass" file which we'd inherit in the recipes
> > where we've got ptest enabled?
> 
> Having looked into it a bit, I'm not sure I understand how you mean.
>
> First, I don't quite see how this would be done in an elegant way for
> the in-function changes in image.bbclass and packagegroup.bbclass. 

Those are pretty non-invasive so I think we can just add these pieces in
directly as you have them now.

> And the lines added to bitbake.conf were put there because they mirror
> other complementary packages like -dbg and -dev. Is it really a good
> idea to invent a new way of doing this for -ptest packages?

This isn't a "new way". We can easily put these in a .bbclass for now.
Pretty much every package has a -dev and -dbg package but for now, the
number of packages which will have ptest is limited. Its a waste of
build time having the -ptest metadata being processed for every package,
its also confusing.

So I think my proposal stands, lets put the pieces from bitbake.conf
into a bbclass file for now, the other pieces can merge into the core
code. As and when we have more than say 60% of the metadata with ptest
we can think about making -ptest packages the default.

Cheers,

Richard
> 





  reply	other threads:[~2012-12-04 17:04 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-22 16:01 [PATCH 0/4] ptest for master Björn Stenberg
2012-11-22 16:01 ` [PATCH 1/4] Add a new distro feature "ptest" Björn Stenberg
2012-11-23 21:49   ` Richard Purdie
2012-11-28 14:44     ` Björn Stenberg
2012-11-29 15:52     ` Björn Stenberg
2012-12-04 16:49       ` Richard Purdie [this message]
2012-12-05 10:17         ` Björn Stenberg
2012-11-22 16:01 ` [PATCH 2/4] New package: ptest-runner Björn Stenberg
2012-11-22 16:01 ` [PATCH 3/4] Add ptest for glib Björn Stenberg
2012-11-23 21:50   ` Richard Purdie
2012-11-28 13:32   ` Björn Stenberg
2012-11-22 16:02 ` [PATCH 4/4] Add ptest for dbus Björn Stenberg
2012-11-22 16:06   ` Otavio Salvador
2012-11-23 21:46   ` Richard Purdie
  -- strict thread matches above, loose matches on Subject: below --
2012-11-21 15:23 [PATCH 0/4] RFC: ptest for danny Björn Stenberg
2012-11-21 15:23 ` [PATCH 1/4] Add a new distro feature "ptest" 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=1354639762.25268.54.camel@ted \
    --to=richard.purdie@linuxfoundation.org \
    --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