Difference between pages "Portage Profile Logic" and "News:New OpenGL management in Funtoo"

(Difference between pages)
 
(explanation of the new system)
 
Line 1: Line 1:
== Gentoo Initialization ==
+
{{News
 +
|Summary=Funtoo is switching to an improved system for managing multiple OpenGL providers (Mesa/Xorg, AMD and nVidia). The update may involve blockers and file collisions.
 +
|News Format=Extended
 +
|News Category=Packages
 +
|Author=Mgorny
 +
|Publication Status=Draft
 +
|Publication Date=2015/02/28
 +
}}
 +
== New OpenGL management ==
 +
=== System principles ===
 +
The new OpenGL management design assumes that the reference OpenGL implementation (mesa/Xorg) is to be used to build packages. After switching to the new system, all packages will use the mesa/Xorg headers and link to the mesa/Xorg libraries. This improves portability of software built on Funtoo and solves some of the build failures when non-standard OpenGL provider was enabled.
  
Gentoo profile initialization has been documented in [https://github.com/funtoo/portage-funtoo/commit/4c6826a0029c3c8f0aa92e70b4e50f2ffc58c7fa#diff-0 this GitHub commit], and describes how Gentoo's Portage finds and processes profiles. Funtoo Linux will be making some changes to this algorithm, but first things first -- document the existing functionality. Basically, Gentoo's Portage looks for profiles using this algorithm:
+
The third-party OpenGL libraries and modules provided by proprietary driver vendors can be enabled for run-time program use. They will not affect how the program is built. However, they will be loaded by the dynamic loader when starting executables. The Xorg server will also load the modules provided by blob driver vendor if appropriate.
  
# Does <tt>/etc/make.profile</tt> exist? If so, it defines the primary profile.
+
=== Implementation ===
# If not, does <tt>/etc/portage/make.profile</tt> exist? If so, it defines the primary profile.
+
The reference implementation (mesa/Xorg) packages install headers and libraries into standard system locations (/usr/include, /usr/lib*). The compiler and linker finds them using the usual rules and uses them.
# Recursively process the <tt>parent</tt> file found in the primary profile to build a list of all cascading profiles
+
# if <tt>/etc/portage/profile</tt> exists, it is a user-defined profile - tack it to the end of our profile list so it can modify anything in the cascading profiles.
+
  
Here is a more detailed description of the steps:
+
The third-party OpenGL vendors install libraries and server extension modules into vendor-named subdirectories of /usr/lib*/opengl. Those files are not used directly.
  
# Look for a profile directory/symlink at <tt>/etc/make.profile</tt>, if one exists, use this as the main profile directory.
+
{{Package|app-admin/eselect-opengl}} is used to select OpenGL implementation used at run-time. The choice of implementation is controlled via dynamic linker configuration (ld.so.conf) and Xorg server configuration. If the reference implementation is selected, the eselect module outputs null configuration that causes the linker and server to use the standard paths. If an another implementation is selected, the configuration prepends /usr/lib*/opengl paths to linker and server configuration, causing them to prefer the third-party libraries over reference.
# If <tt>/etc/make.profile</tt> doesn't exist, use <tt>/etc/portage/make.profile</tt> as a back-up location if it exists.
+
{{NewsFooter}}
# If neither location exists, then a main profile directory doesn't exist and is undefined (None)
+
 
+
Using the main profile directory/symlink found above, the <tt>LocationsManager._addProfile()</tt> recursive function will be called that will create a list of all cascading profiles. This works by looking for a <tt>parent</tt> file in the profile directory. If this file exists, then each line is treated as a ''relative path'' and used to modify the path to the current profile, pointing to a "parent" profile that this particular profile modifies. There can be more than one parent, one per line. ''The first line in the <tt>parent</tt> file is the highest-priority parent.''
+
 
+
Once this list is created, the code checks to see if <tt>/etc/portage/profile</tt> directory exists. If it does, it is tacked at the end of the cascading profile list, meaning that it is evaluated last and this user-defined profile has the ability to modify any of the cascading profile settings. It provides an ideal hook point for a user-defined profile that can tweak anything the user wants to modify in the profile.
+
 
+
[[Category:Portage]]
+

Revision as of 18:53, February 28, 2015

New OpenGL management in Funtoo

Funtoo is switching to an improved system for managing multiple OpenGL providers (Mesa/Xorg, AMD and nVidia). The update may involve blockers and file collisions.

By Mgorny / February 28, 2015

New OpenGL management

System principles

The new OpenGL management design assumes that the reference OpenGL implementation (mesa/Xorg) is to be used to build packages. After switching to the new system, all packages will use the mesa/Xorg headers and link to the mesa/Xorg libraries. This improves portability of software built on Funtoo and solves some of the build failures when non-standard OpenGL provider was enabled.

The third-party OpenGL libraries and modules provided by proprietary driver vendors can be enabled for run-time program use. They will not affect how the program is built. However, they will be loaded by the dynamic loader when starting executables. The Xorg server will also load the modules provided by blob driver vendor if appropriate.

Implementation

The reference implementation (mesa/Xorg) packages install headers and libraries into standard system locations (/usr/include, /usr/lib*). The compiler and linker finds them using the usual rules and uses them.

The third-party OpenGL vendors install libraries and server extension modules into vendor-named subdirectories of /usr/lib*/opengl. Those files are not used directly.

Eselect (OpenGL) is used to select OpenGL implementation used at run-time. The choice of implementation is controlled via dynamic linker configuration (ld.so.conf) and Xorg server configuration. If the reference implementation is selected, the eselect module outputs null configuration that causes the linker and server to use the standard paths. If an another implementation is selected, the configuration prepends /usr/lib*/opengl paths to linker and server configuration, causing them to prefer the third-party libraries over reference.

blog comments powered by Disqus