The Funtoo Linux project has transitioned to "Hobby Mode" and this wiki is now read-only.
Difference between revisions of "Package:Eselect (OpenGL)"
Line 4: | Line 4: | ||
|Maintainer= | |Maintainer= | ||
}} | }} | ||
== Introduction == | == Introduction == | ||
Line 41: | Line 39: | ||
show Print the current OpenGL implementation. | show Print the current OpenGL implementation. | ||
</console> | </console> | ||
== What is Switched == | == What is Switched == | ||
Line 58: | Line 55: | ||
** <tt>/usr/include/KHR/*</tt> | ** <tt>/usr/include/KHR/*</tt> | ||
== Criticisms == | |||
=== Violation of Build Consistency === | |||
As documented in {{Bug|FL-1309}}, sometimes packages fail to merge when the "wrong" eselect opengl implementation is selected. This violates Portage's ability to consistently build a package from source, assuming all its dependencies are satisfied. This could be classified as a design bug -- eselect-opengl is functioning as intended, but its underlying theory of operation is not correct. | |||
===== Possible Solutions ===== | |||
A possible solution to this problem, discussed in {{Bug|FL-1309}}, is to redesign eselect-opengl to only select the ''runtime'' OpenGL implementation, but to have all ebuilds build against the official xorg-x11 OpenGL implementation. | |||
The rationale for this design change is that: | |||
# There should be a consistent and repeatable build/linking process for all OpenGL applications. | |||
# AMD and NVIDIA implementations of OpenGL are designed to be more of a "drop-in" runtime replacement for xorg-x11, rather than a standalone replacement for xorg-x11, and thus appear to exhibit more build-time bugs. | |||
Revision as of 19:25, June 28, 2014
Eselect (OpenGL)
We welcome improvements to this page. To edit this page, Create a Funtoo account. Then log in and then click here to edit this page. See our editing guidelines to becoming a wiki-editing pro.
Introduction
Eselect (OpenGL) (also called eselect-opengl) is a module for Eselect that allows the OpenGL implementation on a Funtoo Linux or Gentoo Linux system to be switched between a variety of installed OpenGL implementations. It functions by creating an env,d file at /etc/env.d/03opengl which contains OpenGL settings. A sample env.d file for a multilib system with xorg-x11 OpenGL implementation may look like this:
/etc/env.d/03opengl
- An example env.d file for eselect-opengl# Configuration file for eselect
# This file has been automatically generated.
LDPATH="/usr/lib32/opengl/xorg-x11/lib:/usr/lib64/opengl/xorg-x11/lib"
OPENGL_PROFILE="xorg-x11"
Implementation
Eselect-opengl is implemented as a single bash-based Eselect module approximately 10K in size, installed at /usr/share/eselect/modules/opengl.eselect. One interfaces with this module via the main eselect command:
root # eselect opengl help Manage the OpenGL implementation used by your system Usage: eselect opengl <action> <options> root ##g##Standard actions: help Display help text usage Display usage information version Display version information root ##g##Extra actions: list List the available OpenGL implementations. set <target> Select the OpenGL implementation. <target> The profile to activate --use-old If an implementation is already set, use that one instead --prefix=<val> Set the source prefix (default: /usr) --dst-prefix=<val> Set the destination prefix (default: /usr) --ignore-missing Ignore missing files when setting a new implementation show Print the current OpenGL implementation.
What is Switched
Eselect-opengl handles switching of the active:
- Libraries (32-bit and 64-bit):
- libGL
- libEGL
- libGLESv1
- libGLESv2
- C Headers:
- /usr/include/GL/*
- /usr/include/EGL/*
- /usr/include/KHR/*
Criticisms
Violation of Build Consistency
As documented in FL-1309, sometimes packages fail to merge when the "wrong" eselect opengl implementation is selected. This violates Portage's ability to consistently build a package from source, assuming all its dependencies are satisfied. This could be classified as a design bug -- eselect-opengl is functioning as intended, but its underlying theory of operation is not correct.
Possible Solutions
A possible solution to this problem, discussed in FL-1309, is to redesign eselect-opengl to only select the runtime OpenGL implementation, but to have all ebuilds build against the official xorg-x11 OpenGL implementation.
The rationale for this design change is that:
- There should be a consistent and repeatable build/linking process for all OpenGL applications.
- AMD and NVIDIA implementations of OpenGL are designed to be more of a "drop-in" runtime replacement for xorg-x11, rather than a standalone replacement for xorg-x11, and thus appear to exhibit more build-time bugs.