Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Yann E. MORIN <yann.morin.1998@free.fr>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH] package/opengl: ensure consistency between the various providers
Date: Thu, 16 Feb 2017 18:56:48 +0100	[thread overview]
Message-ID: <20170216175648.GD4986@free.fr> (raw)
In-Reply-To: <681a6c09-1976-193c-a738-ff948ff86567@mind.be>

Arnout, All,

On 2017-02-16 18:46 +0100, Arnout Vandecappelle spake thusly:
> On 14-02-17 22:13, Yann E. MORIN wrote:
> > Some GL providers will provide libegl and libgles, but not libgl, while
> > other will provide libgl but not libegl not libgles. This can be the
> > case with:
> >   - mesa3d       -> libgl
> >   - rpi-userland -> libegl and libgles
> 
>  The commit message is missing an explanation of why this is bad... Something
> like "Such a situation leads to conflicting headers and libraries when building
> a package that uses both libgl and libegl."

OK, I can fix that.

> > Since we can not protect against this situation in the Config.in files
> > (especially because providers may be out-of-tree), we can only check for
> > the validity after the fact.
> 
>  Perhaps it would be possible to create a new opengl virtual package, and that
> the libgl* providers provide opengl instead of the specific libgl. So libgl etc.
> would no longer be virtual packages by themselves, but just suboptions of
> opengl. The libgl* consumers would depend on BR2_PACKAGE_HAS_LIBGL but add
> opengl to their dependencies instead of libgl.

I don't like it, because it means that it is no longer possible to have
out-of-tree providers (e.g. in a br2-external tree).

(If I understood correctly what you are proposing.)

>  Clearly this alternative is too invasive for 2017.02, so your patch is still valid.
> 
> > 
> > Fixes:
> >     http://autobuild.buildroot.org/results/6f1/6f197c643972e92f0b27b3afac7da7b4b1115f7e/
> >     http://autobuild.buildroot.org/results/6c6/6c6e0a236bde7b892a69119a49422119f3efaa97/
> >     http://autobuild.buildroot.org/results/5a2/5a2a1503b7d19c0ca5b0e9093aa24ed9c020e812/
> 
>  Does the autobuilder script filter out errors like these? If not, the
> autobuilder errors will not be fixed, they'll just move...

Clearly, the autobuilder scripts will have to learn to catch this, as
they are currently catching the multiple-providers case.

> > Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
> > Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> > ---
> >  package/opengl/opengl.mk | 29 +++++++++++++++++++++++++++++
> >  1 file changed, 29 insertions(+)
> > 
> > diff --git a/package/opengl/opengl.mk b/package/opengl/opengl.mk
> > index abf96d5..47902f2 100644
> > --- a/package/opengl/opengl.mk
> > +++ b/package/opengl/opengl.mk
> > @@ -1 +1,30 @@
> >  include $(sort $(wildcard package/opengl/*/*.mk))
> > +
> > +# Ensure consistency betwenn the various GL providers:
> > +
> > +# If we have a libgl provider, then the libegl provider must be the same
> > +ifeq ($(BR2_PACKAGE_HAS_LIBGL)$(BR2_PACKAGE_HAS_LIBEGL),yy)
> > +# No need to qstrip, both are quoted
> > +ifneq ($(BR2_PACKAGE_PROVIDES_LIBGL),$(BR2_PACKAGE_PROVIDES_LIBEGL))
> > +$(error Provider for libgl ($(BR2_PACKAGE_PROVIDES_LIBGL)) is not the same \
> > +	as for libegl ($(BR2_PACKAGE_PROVIDES_LIBEGL)))
> > +endif
> > +endif
> 
>  Shouldn't all this be protected by BR_BUILDING?

I was wondering if we should have it, so that we could re-enter the
menuconfig in case of error, but it seems that it was not needed.

And we do not want to allow 'make source' either, sonce the
configuration is invalid.

What are you trying to protect against (here) with BR_BUILDING?

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

  reply	other threads:[~2017-02-16 17:56 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-14 21:13 [Buildroot] [PATCH] package/opengl: ensure consistency between the various providers Yann E. MORIN
2017-02-16 17:46 ` Arnout Vandecappelle
2017-02-16 17:56   ` Yann E. MORIN [this message]
2017-02-17  7:56     ` Arnout Vandecappelle
2017-02-17 22:19       ` Yann E. MORIN
2017-02-17  8:34   ` Jérôme Pouiller
2017-02-17 10:04     ` Thomas Petazzoni
2017-02-17 17:06       ` Jérôme Pouiller
2017-03-26 21:48 ` Thomas Petazzoni

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=20170216175648.GD4986@free.fr \
    --to=yann.morin.1998@free.fr \
    --cc=buildroot@busybox.net \
    /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