Difference between pages "Coding Standards" and "News:New OpenGL management in Funtoo"

(Difference between pages)
 
(explanation of the new system)
 
Line 1: Line 1:
== Basic Coding Standards In A Nutshell ==
+
{{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.
  
* word wrap at 160 characters
+
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.
* use tabs, not spaces, for indentation
+
* use a tab size of 4 characters (tab size can be adjusted but it affects when you reach the magic 160 char wrap limit)
+
* comments on separate lines, at same indent level as code (sections can be marked by 'outdented' comments)
+
  
== Word Wrap ==
+
=== 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.
  
Modern editors do a good job of displaying very long lines of text, and modern displays have sufficient resolution for displaying much more than 80 characters per line, even at 1024x768 resolution. You should definitely not split an elegant single-line piece of code into multiple lines just for the sake of keeping the whole thing under 80 characters. It's especially bad if you take, say, a 100-character line and split it into ''more'' than two lines just for the sake of keeping it under 80 characters in length. But you need or want to use multiple lines to keep your code readable, more power to you. Don't just do it to maintain "Apple IIe with 80-column card compatibility" for any reason. That's just silly.
+
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.
  
== Tabs vs. Spaces ==
+
{{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.
 
+
{{NewsFooter}}
Tabs and spaces had a fight. Tabs won. They're easier to deal with and allow configurable indentation for those who require it. I don't care what some other group or organization says the convention is. If you don't want to use tabs because you want all your end-of-line comments to line up beautifully, then I have a solution: don't use end-of-line comments (see the next section) and you'll be fine.
+
 
+
== Comments ==
+
 
+
Add comments that provide some insight into your code, and that help to provide context. Also, because we use tabs, place comments on their own lines, separate from source code, ideally separated by a blank line above and below unless you are verbosely commenting every line of code. This also encourages longer, more descriptive comments that may span multiple lines. If you span multiple lines, use a consistent right margin of 160 characters. Comments help you understand your code when you come back to it a year later, so you are adding descriptive comments for yourself as much as for others. Include information you would find helpful if you had a sudden case of amnesia. They are especially important for free/open source software that needs to be maintained by various people over the years.
+
 
+
== Profanity ==
+
 
+
Do not place any profanity in source code comments or variable names. It just makes you look unprofessional, silly and incompetent.
+
 
+
 
+
[[Category:QA]]
+

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