public inbox for openembedded-core@lists.openembedded.org
 help / color / mirror / Atom feed
From: "Phil Blundell" <pb@pbcl.net>
To: Trevor Woerner <twoerner@gmail.com>
Cc: Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>
Subject: Re: [OE-core] [PATCH] mesa.inc: add dispmanx support
Date: Fri, 4 Dec 2020 11:51:41 +0100	[thread overview]
Message-ID: <20201204105141.GU30831@pbcl.net> (raw)
In-Reply-To: <CAHUNapRs_1Dz6ARBfgLk7i3DXx0HHbRgC5u7U=3njQb3ht4cbw@mail.gmail.com>

On Thu, Dec 03, 2020 at 05:35:23PM -0500, Trevor Woerner wrote:
> On Thu, Dec 3, 2020 at 5:25 PM Phil Blundell <pb@pbcl.net> wrote:
> 
> > If we're talking about OpenGLES applications, wouldn't you already have
> > opengl in DISTRO_FEATURES?
> >
> 
> Not necessarily.
> 
> Adding opengl to DISTRO_FEATURES really means "enable a bunch of
> PACKAGECONFIGs all over the place because I need x11 and mesa with all the
> bells and whistles".

It sounds like there are a few things that have gone wrong here then.
Firstly, "opengl" in DISTRO_FEATURES isn't supposed to imply anything
about x11.  If it does, that's just a bug.  It should indeed enable opengl
support in other recipes, though.  Can you give an example of the sort
of thing that's getting enabled there that you don't want?

But secondly, thinking about it again, there's no reason for mesa itself
to require opengl in DISTRO_FEATURES anyway.  Mesa itself is what provides
the GL API so it clearly doesn't depend on it.  I think that existing
DISTRO_FEATURE check in mesa is just bogus and should be removed entirely.

> As I mentioned to Khem, I added this patch in order to support the changes
> I made to the recipe for glmark2 in meta-openembedded. If those can be done
> in a bbappend in the BSP layer then I'd be happy to re-asses, but I don't
> think they can.

It's a bit hard to say anything intelligent about that without knowing what
the changes are.  Can you summarise what the issue is?

> Maybe a better question is: does adding this DISTRO_FEATURE hurt anything
> in oe-core?

Clearly it doesn't actually break anything, but it's going to be a bit of
a maintenance burden because it won't be very obvious to anybody else
working on the recipes what it's supposed to mean.

p.


  reply	other threads:[~2020-12-04 10:51 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-03 13:35 [PATCH] mesa.inc: add dispmanx support Trevor Woerner
2020-12-03 19:00 ` [OE-core] " Khem Raj
2020-12-03 21:54   ` Trevor Woerner
2020-12-03 22:02 ` Phil Blundell
2020-12-03 22:35   ` Trevor Woerner
2020-12-04 10:51     ` Phil Blundell [this message]
2020-12-11  2:48       ` Trevor Woerner

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=20201204105141.GU30831@pbcl.net \
    --to=pb@pbcl.net \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=twoerner@gmail.com \
    /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