Difference between pages "Portage Profile Logic" and "Talk:Coding Standards"

From Funtoo
(Difference between pages)
Jump to navigation Jump to search
 
(I put some comments of my own.)
 
Line 1: Line 1:
== Gentoo Initialization ==
Screens may be able to handle more than 80 characters. Printers don't, and people do like to print out code from time to time to look at on paper. So, go bigger than 80 characters when you need to, not just because you can. There are usually ways to make it fit. Long lines can also indicate you are doing something too complex, so maybe it should be split into its own method or function.


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:
I don't personally have a bias in general regarding tabs or spaces. Things are bound to mess up either way. However, I do prefer sticking with the the language's preferred convention if there is one. In the case of Python, that is spaces where an indent consists of four spaces. This makes for consistency when you work with integrating external code, which should generally follow the established convention of the language.


# Does <tt>/etc/make.profile</tt> exist? If so, it defines the primary profile.
I never originally knew what they were, but many editors have mode lines. I suggest including them. This communicates the formatting preference in the document, and many text editors support them to some degree.
# If not, does <tt>/etc/portage/make.profile</tt> exist? If so, it defines the primary profile.
# 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:
--[[User:Brantgurga|Brantgurga]] 03:29, 29 December 2010 (CET)
 
# Look for a profile directory/symlink at <tt>/etc/make.profile</tt>, if one exists, use this as the main profile directory.
# If <tt>/etc/make.profile</tt> doesn't exist, use <tt>/etc/portage/make.profile</tt> as a back-up location if it exists.
# 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]]

Latest revision as of 02:29, December 29, 2010

Screens may be able to handle more than 80 characters. Printers don't, and people do like to print out code from time to time to look at on paper. So, go bigger than 80 characters when you need to, not just because you can. There are usually ways to make it fit. Long lines can also indicate you are doing something too complex, so maybe it should be split into its own method or function.

I don't personally have a bias in general regarding tabs or spaces. Things are bound to mess up either way. However, I do prefer sticking with the the language's preferred convention if there is one. In the case of Python, that is spaces where an indent consists of four spaces. This makes for consistency when you work with integrating external code, which should generally follow the established convention of the language.

I never originally knew what they were, but many editors have mode lines. I suggest including them. This communicates the formatting preference in the document, and many text editors support them to some degree.

--Brantgurga 03:29, 29 December 2010 (CET)