Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-dev
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-dev@g.o
From: Luca Barbato <lu_zero@g.o>
Subject: Supporting GLES-only implementations
Date: Sat, 03 Mar 2012 18:26:22 +0100
I'm trying to get better support for efika and possibly other similar
systems like pandaboard.

I already started to hack eselect-opengl and mesa to keep libGLES*,
libOpenVG and libEGL in the switchable dir and it seems to work properly.

Now I'd like to make ALL the GL/ GLES/ KHR/ and such headers switchable
as well.

One of the last items is discussing about what to do with
implementations that do not provide OpenGL.

I'd introduce a separate virtual for gles2, gles1 and openvg and make so
eselect-opengl does not complain if libGL is missing.

Anybody has interest and/or better ideas?

lu

PS: I'd consider GL implementations monolithic so you cannot mix and
match them at least for now.

-- 

Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero



Replies:
Re: Supporting GLES-only implementations
-- Luca Barbato
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: [gentoo-commits] gentoo-x86 commit in dev-scheme/racket: ChangeLog racket-5.2.1.ebuild
Next by thread:
Re: Supporting GLES-only implementations
Previous by date:
Re: Re: [gentoo-python] New eclass for Python
Next by date:
Packages up for grabs due ken69267 retirement


Updated Jun 29, 2012

Summary: Archive of the gentoo-dev mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.