| … | |
… | |
| 31 | <tbody valign="top"> |
31 | <tbody valign="top"> |
| 32 | <tr class="field"><th class="field-name">GLEP:</th><td class="field-body">47</td> |
32 | <tr class="field"><th class="field-name">GLEP:</th><td class="field-body">47</td> |
| 33 | </tr> |
33 | </tr> |
| 34 | <tr class="field"><th class="field-name">Title:</th><td class="field-body">Creating 'safe' environment variables</td> |
34 | <tr class="field"><th class="field-name">Title:</th><td class="field-body">Creating 'safe' environment variables</td> |
| 35 | </tr> |
35 | </tr> |
| 36 | <tr class="field"><th class="field-name">Version:</th><td class="field-body">1.8</td> |
36 | <tr class="field"><th class="field-name">Version:</th><td class="field-body">1.1</td> |
| 37 | </tr> |
37 | </tr> |
| 38 | <tr class="field"><th class="field-name">Last-Modified:</th><td class="field-body"><a class="reference" href="http://www.gentoo.org/cgi-bin/viewcvs/xml/htdocs/proj/en/glep/glep-0047.txt?cvsroot=gentoo">2006/01/26 20:56:55</a></td> |
38 | <tr class="field"><th class="field-name">Last-Modified:</th><td class="field-body"><a class="reference" href="http://www.gentoo.org/cgi-bin/viewcvs/xml/htdocs/proj/en/glep/glep-0047.txt?cvsroot=gentoo">2006/02/09 21:42:57</a></td> |
| 39 | </tr> |
39 | </tr> |
| 40 | <tr class="field"><th class="field-name">Author:</th><td class="field-body">Diego Pettenò, Fabian rroffen <{flameeyes,grobian}@gentoo.org></td> |
40 | <tr class="field"><th class="field-name">Author:</th><td class="field-body">Diego Pettenò, Fabian Groffen</td> |
| 41 | </tr> |
41 | </tr> |
| 42 | <tr class="field"><th class="field-name">Status:</th><td class="field-body">Active</td> |
42 | <tr class="field"><th class="field-name">Status:</th><td class="field-body">Draft</td> |
| 43 | </tr> |
43 | </tr> |
| 44 | <tr class="field"><th class="field-name">Type:</th><td class="field-body">Proposal</td> |
44 | <tr class="field"><th class="field-name">Type:</th><td class="field-body">Standards Track</td> |
| 45 | </tr> |
45 | </tr> |
| 46 | <tr class="field"><th class="field-name">Content-Type:</th><td class="field-body"><a class="reference" href="glep-0012.html">text/x-rst</a></td> |
46 | <tr class="field"><th class="field-name">Content-Type:</th><td class="field-body"><a class="reference" href="glep-0012.html">text/x-rst</a></td> |
| 47 | </tr> |
47 | </tr> |
| 48 | <tr class="field"><th class="field-name">Created:</th><td class="field-body">14-Oct-2005</td> |
48 | <tr class="field"><th class="field-name">Created:</th><td class="field-body">14-Oct-2005</td> |
| 49 | </tr> |
49 | </tr> |
| 50 | <tr class="field"><th class="field-name">Post-History:</th><td class="field-body"></td> |
50 | <tr class="field"><th class="field-name">Post-History:</th><td class="field-body">09-Feb-2006</td> |
| 51 | </tr> |
51 | </tr> |
| 52 | </tbody> |
52 | </tbody> |
| 53 | </table> |
53 | </table> |
| 54 | <hr /> |
54 | <hr /> |
| 55 | <div class="contents topic" id="contents"> |
55 | <div class="contents topic" id="contents"> |
| 56 | <p class="topic-title first"><a name="contents">Contents</a></p> |
56 | <p class="topic-title first"><a name="contents">Contents</a></p> |
| 57 | <ul class="simple"> |
57 | <ul class="simple"> |
| 58 | <li><a class="reference" href="#credits" id="id9" name="id9">Credits</a></li> |
58 | <li><a class="reference" href="#credits" id="id5" name="id5">Credits</a></li> |
| 59 | <li><a class="reference" href="#abstract" id="id10" name="id10">Abstract</a></li> |
59 | <li><a class="reference" href="#abstract" id="id6" name="id6">Abstract</a></li> |
| 60 | <li><a class="reference" href="#motivation" id="id11" name="id11">Motivation</a></li> |
60 | <li><a class="reference" href="#motivation" id="id7" name="id7">Motivation</a></li> |
| 61 | <li><a class="reference" href="#rationale" id="id12" name="id12">Rationale</a></li> |
61 | <li><a class="reference" href="#rationale" id="id8" name="id8">Rationale</a></li> |
| 62 | <li><a class="reference" href="#backwards-compatibility" id="id13" name="id13">Backwards Compatibility</a></li> |
62 | <li><a class="reference" href="#backwards-compatibility" id="id9" name="id9">Backwards Compatibility</a></li> |
| 63 | <li><a class="reference" href="#specification" id="id14" name="id14">Specification</a><ul> |
63 | <li><a class="reference" href="#specification" id="id10" name="id10">Specification</a><ul> |
| 64 | <li><a class="reference" href="#variables" id="id15" name="id15">Variables</a></li> |
64 | <li><a class="reference" href="#variable-assignment" id="id11" name="id11">Variable Assignment</a></li> |
| 65 | </ul> |
65 | </ul> |
| 66 | </li> |
66 | </li> |
| 67 | <li><a class="reference" href="#references" id="id16" name="id16">References</a></li> |
67 | <li><a class="reference" href="#references" id="id12" name="id12">References</a></li> |
| 68 | <li><a class="reference" href="#copyright" id="id17" name="id17">Copyright</a></li> |
68 | <li><a class="reference" href="#copyright" id="id13" name="id13">Copyright</a></li> |
| 69 | </ul> |
69 | </ul> |
| 70 | </div> |
70 | </div> |
| 71 | <div class="section" id="credits"> |
71 | <div class="section" id="credits"> |
| 72 | <h1><a class="toc-backref" href="#id9" name="credits">Credits</a></h1> |
72 | <h1><a class="toc-backref" href="#id5" name="credits">Credits</a></h1> |
| 73 | <p>The text of this GLEP is a result of a discussion and input of the |
73 | <p>The text of this GLEP is a result of a discussion and input of the |
| 74 | following persons, in no particular order: Mike Frysinger, Diego |
74 | following persons, in no particular order: Mike Frysinger, Diego |
| 75 | Pettenò, Fabian Groffen and Finn Thain.</p> |
75 | Pettenò, Fabian Groffen and Finn Thain.</p> |
| 76 | </div> |
76 | </div> |
| 77 | <div class="section" id="abstract"> |
77 | <div class="section" id="abstract"> |
| 78 | <h1><a class="toc-backref" href="#id10" name="abstract">Abstract</a></h1> |
78 | <h1><a class="toc-backref" href="#id6" name="abstract">Abstract</a></h1> |
| 79 | <p>In order for ebuilds and eclasses to be able to make host specific |
79 | <p>In order for ebuilds and eclasses to be able to make host specific |
| 80 | decisions, it is necessary to have a number of environmental variables |
80 | decisions, it is necessary to have a number of environmental variables |
| 81 | which allow for such decisions. This GLEP introduces some measures that |
81 | which allow for such decisions. This GLEP introduces some measures that |
| 82 | need to be made to make these decisions 'safe', by making sure the |
82 | need to be made to make these decisions 'safe', by making sure the |
| 83 | variables the decisions are based on are 'safe'. A small overlap with |
83 | variables the decisions are based on are 'safe'. A small overlap with |
| 84 | GLEP 22 <a class="footnote-reference" href="#id5" id="id1" name="id1">[1]</a> is being handled in this GLEP where the use of 2-tuple |
84 | GLEP 22 <a class="footnote-reference" href="#id3" id="id1" name="id1">[1]</a> is being handled in this GLEP where the use of 2-tuple |
| 85 | keywords are being kept instead of 4-tuple keywords. Additionally, the |
85 | keywords are being kept instead of 4-tuple keywords. Additionally, the |
| 86 | <tt class="literal"><span class="pre">ELIBC</span></tt>, <tt class="literal"><span class="pre">KERNEL</span></tt> and <tt class="literal"><span class="pre">ARCH</span></tt> get auto filled starting from |
86 | <tt class="literal"><span class="pre">ELIBC</span></tt>, <tt class="literal"><span class="pre">KERNEL</span></tt> and <tt class="literal"><span class="pre">ARCH</span></tt> get auto filled starting from |
| 87 | <tt class="literal"><span class="pre">CHOST</span></tt> and the 2-tuple keyword, instead of solely from they 4-tuple |
87 | <tt class="literal"><span class="pre">CHOST</span></tt> and the 2-tuple keyword, instead of solely from they 4-tuple |
| 88 | keyword as proposed in GLEP 22.</p> |
88 | keyword as proposed in GLEP 22.</p> |
| 89 | <p>The destiny of the <tt class="literal"><span class="pre">USERLAND</span></tt> variable is out of the scope of this |
89 | <p>The destiny of the <tt class="literal"><span class="pre">USERLAND</span></tt> variable is out of the scope of this |
| 90 | GLEP. Depending on its presence in the tree, it may be decided to set |
90 | GLEP. Depending on its presence in the tree, it may be decided to set |
| 91 | this variable the same way we propose to set <tt class="literal"><span class="pre">ELIBC</span></tt>, <tt class="literal"><span class="pre">KERNEL</span></tt> and |
91 | this variable the same way we propose to set <tt class="literal"><span class="pre">ELIBC</span></tt>, <tt class="literal"><span class="pre">KERNEL</span></tt> and |
| 92 | <tt class="literal"><span class="pre">ARCH</span></tt>, or alternatively, e.g. via the profiles.</p> |
92 | <tt class="literal"><span class="pre">ARCH</span></tt>, or alternatively, e.g. via the profiles.</p> |
| 93 | </div> |
93 | </div> |
| 94 | <div class="section" id="motivation"> |
94 | <div class="section" id="motivation"> |
| 95 | <h1><a class="toc-backref" href="#id11" name="motivation">Motivation</a></h1> |
95 | <h1><a class="toc-backref" href="#id7" name="motivation">Motivation</a></h1> |
| 96 | <p>The Gentoo/Alt project is in an emerging state to get ready to serve a |
96 | <p>The Gentoo/Alt project is in an emerging state to get ready to serve a |
| 97 | plethora of 'alternative' configurations such as FreeBSD, NetBSD, |
97 | plethora of 'alternative' configurations such as FreeBSD, NetBSD, |
| 98 | DragonflyBSD, GNU/kFreeBSD, Mac OS X, (Open)Darwin, (Open)Solaris and so |
98 | DragonflyBSD, GNU/kFreeBSD, Mac OS X, (Open)Darwin, (Open)Solaris and so |
| 99 | on. As such, the project is in need for a better grip on the actual |
99 | on. As such, the project is in need for a better grip on the actual |
| 100 | host being built on. This information on the host environment is |
100 | host being built on. This information on the host environment is |
| 101 | necessary to make proper (automated) decisions on settings that are |
101 | necessary to make proper (automated) decisions on settings that are |
| 102 | highly dependant on the build environment, such as platform or as in |
102 | highly dependant on the build environment, such as platform or C-library |
| 103 | <a class="footnote-reference" href="#id6" id="id2" name="id2">[2]</a>.</p> |
103 | implementation.</p> |
| 104 | </div> |
104 | </div> |
| 105 | <div class="section" id="rationale"> |
105 | <div class="section" id="rationale"> |
| 106 | <h1><a class="toc-backref" href="#id12" name="rationale">Rationale</a></h1> |
106 | <h1><a class="toc-backref" href="#id8" name="rationale">Rationale</a></h1> |
| 107 | <p>Gentoo's unique Portage system allows easy installation of applications |
107 | <p>Gentoo's unique Portage system allows easy installation of applications |
| 108 | from source packages. Compiling sources is prone to many environmental |
108 | from source packages. Compiling sources is prone to many environmental |
| 109 | settings and availability of certain tools. Only recently the Gentoo |
109 | settings and availability of certain tools. Only recently the Gentoo |
| 110 | for FreeBSD project has started, as second Gentoo project that operates |
110 | for FreeBSD project has started, as second Gentoo project that operates |
| 111 | on a foreign host operating system using foreign (non-GNU) C-libraries |
111 | on a foreign host operating system using foreign (non-GNU) C-libraries |
| … | |
… | |
| 117 | Since decisions based on this information can be vital, it is of high |
117 | Since decisions based on this information can be vital, it is of high |
| 118 | importance that this information can be trusted and the values can be |
118 | importance that this information can be trusted and the values can be |
| 119 | considered 'safe' and correct.</p> |
119 | considered 'safe' and correct.</p> |
| 120 | </div> |
120 | </div> |
| 121 | <div class="section" id="backwards-compatibility"> |
121 | <div class="section" id="backwards-compatibility"> |
| 122 | <h1><a class="toc-backref" href="#id13" name="backwards-compatibility">Backwards Compatibility</a></h1> |
122 | <h1><a class="toc-backref" href="#id9" name="backwards-compatibility">Backwards Compatibility</a></h1> |
| 123 | <p>The proposed keywording scheme in this GLEP is fully compatible with the |
123 | <p>The proposed keywording scheme in this GLEP is fully compatible with the |
| 124 | current situation of the portage tree, this in contrast to GLEP 22. The |
124 | current situation of the portage tree, this in contrast to GLEP 22. The |
| 125 | variables provided by GLEP 22 can't be extracted from the new keyword, |
125 | variables provided by GLEP 22 can't be extracted from the new keyword, |
| 126 | but since GLEP 22-style keywords aren't in the tree at the moment, that |
126 | but since GLEP 22-style keywords aren't in the tree at the moment, that |
| 127 | is not a problem. The same information can be extracted from the CHOST |
127 | is not a problem. The same information can be extracted from the CHOST |
| 128 | variable, if necessary. No modifications to ebuilds will have to be |
128 | variable, if necessary. No modifications to ebuilds will have to be |
| 129 | made.</p> |
129 | made.</p> |
| 130 | </div> |
130 | </div> |
| 131 | <div class="section" id="specification"> |
131 | <div class="section" id="specification"> |
| 132 | <h1><a class="toc-backref" href="#id14" name="specification">Specification</a></h1> |
132 | <h1><a class="toc-backref" href="#id10" name="specification">Specification</a></h1> |
| 133 | <p>Unlike GLEP 22 the current keyword scheme as used in practice is not |
133 | <p>Unlike GLEP 22 the currently used keyword scheme is not changed. |
| 134 | changed. Instead of proposing a 4-tuple <a class="footnote-reference" href="#id7" id="id3" name="id3">[3]</a> keyword, a 2-tuple |
134 | Instead of proposing a 4-tuple <a class="footnote-reference" href="#id4" id="id2" name="id2">[2]</a> keyword, a 2-tuple keyword is chosen |
| 135 | keyword is chosen for archs that require them. Archs for which a |
135 | for archs that require them. Archs for which a 1-tuple keyword |
| 136 | 1-tuple keyword suffices, keep that keyword. Since this doesn't change |
136 | suffices, can keep that keyword. Since this doesn't change anything to |
| 137 | anything to the current situation in the tree, it is considered to be a |
137 | the current situation in the tree, it is considered to be a big |
| 138 | big advantage over the 4-tuple keyword from GLEP 22. This GLEP is an |
138 | advantage over the 4-tuple keyword from GLEP 22. This GLEP is an |
| 139 | official specification of the syntax of the keyword.</p> |
139 | official specification of the syntax of the keyword.</p> |
| 140 | <p>Keywords will consist out of two parts separated by a hyphen ('-'). The |
140 | <p>Keywords will consist out of two parts separated by a hyphen ('-'). The |
| 141 | left hand part of the keyword 2-tuple is the architecture, such as |
141 | left hand part of the keyword 2-tuple is the architecture, such as |
| 142 | ppc64, sparc and x86. The right hand part indicates the operating |
142 | ppc64, sparc and x86. The right hand part indicates the operating |
| 143 | system or distribution, such as linux, macos, darwin, obsd, etc. If the |
143 | system or distribution, such as linux, macos, darwin, obsd, etc. If the |
| 144 | right hand part is omitted, it implies the operating system/distribution |
144 | right hand part is omitted, it implies the operating system/distribution |
| 145 | type is GNU/Linux. In such case the hyphen is also omitted. Examples |
145 | type is Gentoo GNU/Linux. In such case the hyphen is also omitted. |
| 146 | of such keywords are ppc-darwin and x86. This is fully compatible with |
146 | Examples of such keywords are ppc-darwin and x86. This is fully |
| 147 | the current keywords used in the tree.</p> |
147 | compatible with the current use of keywords in the tree.</p> |
| 148 | <p>The variables <tt class="literal"><span class="pre">ELIBC</span></tt>, <tt class="literal"><span class="pre">KERNEL</span></tt> and <tt class="literal"><span class="pre">ARCH</span></tt> are currently set in |
148 | <p>The variables <tt class="literal"><span class="pre">ELIBC</span></tt>, <tt class="literal"><span class="pre">KERNEL</span></tt> and <tt class="literal"><span class="pre">ARCH</span></tt> are currently set in |
| 149 | the profiles when other than their defaults for a GNU/Linux system. |
149 | the profiles when other than their defaults for a GNU/Linux system. |
| 150 | They can as such easily be overridden and defined by the user. To |
150 | They can as such easily be overridden and defined by the user. To |
| 151 | prevent this from happening, the variables should be auto filled by |
151 | prevent this from happening, the variables should be auto filled by |
| 152 | Portage itself, based on the <tt class="literal"><span class="pre">CHOST</span></tt> variable.</p> |
152 | Portage itself, based on the <tt class="literal"><span class="pre">CHOST</span></tt> variable. While the <tt class="literal"><span class="pre">CHOST</span></tt> |
|
|
153 | variable can be as easy as the others set by the user, it still is |
|
|
154 | assumed to be 'safe'. This assumption is grounded in the fact that the |
|
|
155 | variable itself is being used in various other places with the same |
|
|
156 | intention, and that an invalid <tt class="literal"><span class="pre">CHOST</span></tt> will cause major malfunctioning |
|
|
157 | of the system. A user that changes the <tt class="literal"><span class="pre">CHOST</span></tt> into something that is |
|
|
158 | not valid for the system, is already warned that this might render the |
|
|
159 | system unusable. Concluding, the 'safeness' of the <tt class="literal"><span class="pre">CHOST</span></tt> variable |
|
|
160 | is based on externally assumed 'safeness', which's discussion falls |
|
|
161 | outside this GLEP.</p> |
|
|
162 | <p>Current USE-expansion of the variables is being maintained, as this |
|
|
163 | results in full backward compatibility. Since the variables themself |
|
|
164 | don't change in what they represent, but only how they are being |
|
|
165 | assigned, there should be no problem in maintaining them. Using |
|
|
166 | USE-expansion, conditional code can be written down in ebuilds, which is |
|
|
167 | not different from any existing methods at all:</p> |
|
|
168 | <pre class="literal-block"> |
|
|
169 | ... |
|
|
170 | RDEPEND="elibc_FreeBSD? ( sys-libs/com_err )" |
|
|
171 | ... |
|
|
172 | src_compile() { |
|
|
173 | ... |
|
|
174 | use elibc_FreeBSD && myconf="${myconf} -Dlibc=/usr/lib/libc.a" |
|
|
175 | ... |
|
|
176 | } |
|
|
177 | </pre> |
|
|
178 | <p>Alternatively, the variables <tt class="literal"><span class="pre">ELIBC</span></tt>, <tt class="literal"><span class="pre">KERNEL</span></tt> and <tt class="literal"><span class="pre">ARCH</span></tt> |
|
|
179 | are available in the ebuild evironment and they can be used instead of |
|
|
180 | invoking <tt class="literal"><span class="pre">xxx_Xxxx</span></tt> or in switch statements where they are actually |
|
|
181 | necessary.</p> |
| 153 | <p>A map file can be used to have the various <tt class="literal"><span class="pre">CHOST</span></tt> values being |
182 | <p>A map file can be used to have the various <tt class="literal"><span class="pre">CHOST</span></tt> values being |
| 154 | translated to the correct values for the four variables. This change is |
183 | translated to the correct values for the four variables. This change is |
| 155 | invisible for ebuilds and eclasses, but allows to rely on these |
184 | invisible for ebuilds and eclasses, but allows to rely on these |
| 156 | variables as they are based on a 'safe' value -- the <tt class="literal"><span class="pre">CHOST</span></tt> variable. |
185 | variables as they are based on a 'safe' value -- the <tt class="literal"><span class="pre">CHOST</span></tt> variable. |
| 157 | Ebuilds should not be sensitive to the keyword value, but use the |
186 | Ebuilds should not be sensitive to the keyword value, but use the |
| 158 | aforementioned four variables instead. They allow specific tests for |
187 | aforementioned four variables instead. They allow specific tests for |
| 159 | properties. If this is undesirable, the full <tt class="literal"><span class="pre">CHOST</span></tt> variable can be |
188 | properties. If this is undesirable, the full <tt class="literal"><span class="pre">CHOST</span></tt> variable can be |
| 160 | used to match a complete operating system.</p> |
189 | used to match a complete operating system.</p> |
| 161 | <p>Current USE-expansion is being maintained, for backwards compatibility. |
|
|
| 162 | Since the expansion is based on the variables mentioned above which do |
|
|
| 163 | not change, but only in the way they are generated, there should be no |
|
|
| 164 | problem in maintaining them.</p> |
|
|
| 165 | <div class="section" id="variables"> |
190 | <div class="section" id="variable-assignment"> |
| 166 | <h2><a class="toc-backref" href="#id15" name="variables">Variables</a></h2> |
191 | <h2><a class="toc-backref" href="#id11" name="variable-assignment">Variable Assignment</a></h2> |
| 167 | <p>The <tt class="literal"><span class="pre">ELIBC</span></tt>, <tt class="literal"><span class="pre">KERNEL</span></tt>, <tt class="literal"><span class="pre">ARCH</span></tt> variables are filled from a profile |
192 | <p>The <tt class="literal"><span class="pre">ELIBC</span></tt>, <tt class="literal"><span class="pre">KERNEL</span></tt>, <tt class="literal"><span class="pre">ARCH</span></tt> variables are filled from a profile |
| 168 | file. The file can be overlaid, such that the following entries in the |
193 | file. The file can be overlaid, such that the following entries in the |
| 169 | map file (on the left of the arrow) will result in the assigned |
194 | map file (on the left of the arrow) will result in the assigned |
| 170 | variables on the right hand side of the arrow:</p> |
195 | variables on the right hand side of the arrow:</p> |
| 171 | <pre class="literal-block"> |
196 | <pre class="literal-block"> |
| … | |
… | |
| 175 | *-*-freebsd* -> KERNEL="FreeBSD" ELIBC="FreeBSD" |
200 | *-*-freebsd* -> KERNEL="FreeBSD" ELIBC="FreeBSD" |
| 176 | *-*-darwin* -> KERNEL="Darwin" ELIBC="Darwin" |
201 | *-*-darwin* -> KERNEL="Darwin" ELIBC="Darwin" |
| 177 | *-*-netbsd* -> KERNEL="NetBSD" ELIBC="NetBSD" |
202 | *-*-netbsd* -> KERNEL="NetBSD" ELIBC="NetBSD" |
| 178 | *-*-solaris* -> KERNEL="Solaris" ELIBC="Solaris" |
203 | *-*-solaris* -> KERNEL="Solaris" ELIBC="Solaris" |
| 179 | </pre> |
204 | </pre> |
| 180 | <p>A way to achieve this is proposed by Mike Frysinger <a class="footnote-reference" href="#id8" id="id4" name="id4">[4]</a>, which |
205 | <p>A way to achieve this is proposed by Mike Frysinger, which |
| 181 | suggests to have a env-map file, for instance filled with:</p> |
206 | suggests to have a env-map file, for instance filled with:</p> |
| 182 | <pre class="literal-block"> |
207 | <pre class="literal-block"> |
| 183 | % cat env-map |
208 | % cat env-map |
| 184 | *-linux-* KERNEL=linux |
209 | *-linux-* KERNEL=linux |
| 185 | *-gnu ELIBC=glibc |
210 | *-gnu ELIBC=glibc |
| … | |
… | |
| 208 | <p>Given the example env-map file, this script would result in:</p> |
233 | <p>Given the example env-map file, this script would result in:</p> |
| 209 | <pre class="literal-block"> |
234 | <pre class="literal-block"> |
| 210 | % ./readmap x86_64-pc-linux-gnu |
235 | % ./readmap x86_64-pc-linux-gnu |
| 211 | ARCH=amd64 KERNEL=linux ELIBC=glibc |
236 | ARCH=amd64 KERNEL=linux ELIBC=glibc |
| 212 | </pre> |
237 | </pre> |
|
|
238 | <p>The entries in the <tt class="literal"><span class="pre">env-map</span></tt> file will be evaluated in a forward |
|
|
239 | linear full scan. A side-effect of this exhaustive search is that the |
|
|
240 | variables can be re-assigned if multiple entries match the given |
|
|
241 | <tt class="literal"><span class="pre">CHOST</span></tt>. Because of this, the order of the entries does matter. |
|
|
242 | Because the <tt class="literal"><span class="pre">env-map</span></tt> file size is assumed not to exceed the block |
|
|
243 | size of the file system, the performance penalty of a full scan versus |
|
|
244 | 'first-hit-stop technique' is assumed to be minimal.</p> |
| 213 | <p>It should be noted, however, that the bash script is a proof of concept |
245 | <p>It should be noted, however, that the above bash script is a proof of |
| 214 | implementation. It cannot be used as Portage will need this |
246 | concept implementation. Since Portage is largerly written in Python, it |
| 215 | information, which is written in Python. Hence, an equivalent of this |
247 | will be more efficient to write an equivalent of this code in Python |
| 216 | bash script should be written in Python to be able to use it within |
248 | also. Coding wise, this is considered to be a non-issue, but the format |
| 217 | Portage. This is considered to be a non-issue coding wise.</p> |
249 | of the <tt class="literal"><span class="pre">env-map</span></tt> file, and especially its wildcard characters, might |
|
|
250 | not be the best match with Python. For this purpose, the format |
|
|
251 | specification of the <tt class="literal"><span class="pre">env-map</span></tt> file is deferred to the Python |
|
|
252 | implementation, and only the requirements are given here.</p> |
|
|
253 | <p>The <tt class="literal"><span class="pre">env-map</span></tt> file should be capable of encoding a <tt class="literal"><span class="pre">key</span></tt>, <tt class="literal"><span class="pre">value</span></tt> |
|
|
254 | pair, where <tt class="literal"><span class="pre">key</span></tt> is a (regular) expression that matches a |
|
|
255 | chost-string, and <tt class="literal"><span class="pre">value</span></tt> contains at least one, distinct variable |
|
|
256 | assignment for the variables <tt class="literal"><span class="pre">ARCH</span></tt>, <tt class="literal"><span class="pre">KERNEL</span></tt> and <tt class="literal"><span class="pre">ELIBC</span></tt>. The |
|
|
257 | interpreter of the <tt class="literal"><span class="pre">env-map</span></tt> file must scan the file linearly and |
|
|
258 | continue trying to match the <tt class="literal"><span class="pre">key</span></tt>s and assign variables if |
|
|
259 | appropriate until the end of file.</p> |
|
|
260 | <p>Since Portage will use the <tt class="literal"><span class="pre">env-map</span></tt> file, the location of the file is |
|
|
261 | beyond the scope of this GLEP and up to the Portage implementors.</p> |
| 218 | </div> |
262 | </div> |
| 219 | </div> |
263 | </div> |
| 220 | <div class="section" id="references"> |
264 | <div class="section" id="references"> |
| 221 | <h1><a class="toc-backref" href="#id16" name="references">References</a></h1> |
265 | <h1><a class="toc-backref" href="#id12" name="references">References</a></h1> |
| 222 | <table class="footnote" frame="void" id="id5" rules="none"> |
266 | <table class="footnote" frame="void" id="id3" rules="none"> |
| 223 | <colgroup><col class="label" /><col /></colgroup> |
267 | <colgroup><col class="label" /><col /></colgroup> |
| 224 | <tbody valign="top"> |
268 | <tbody valign="top"> |
| 225 | <tr><td class="label"><a class="fn-backref" href="#id1" name="id5">[1]</a></td><td>GLEP 22, New "keyword" system to incorporate various |
269 | <tr><td class="label"><a class="fn-backref" href="#id1" name="id3">[1]</a></td><td>GLEP 22, New "keyword" system to incorporate various |
| 226 | userlands/kernels/archs, Goodyear, |
270 | userlands/kernels/archs, Goodyear, |
| 227 | (<a class="reference" href="http://glep.gentoo.org/glep-0022.html">http://glep.gentoo.org/glep-0022.html</a>)</td></tr> |
271 | (<a class="reference" href="http://glep.gentoo.org/glep-0022.html">http://glep.gentoo.org/glep-0022.html</a>)</td></tr> |
| 228 | </tbody> |
272 | </tbody> |
| 229 | </table> |
273 | </table> |
| 230 | <table class="footnote" frame="void" id="id6" rules="none"> |
274 | <table class="footnote" frame="void" id="id4" rules="none"> |
| 231 | <colgroup><col class="label" /><col /></colgroup> |
275 | <colgroup><col class="label" /><col /></colgroup> |
| 232 | <tbody valign="top"> |
276 | <tbody valign="top"> |
| 233 | <tr><td class="label"><a class="fn-backref" href="#id2" name="id6">[2]</a></td><td><p>For example in the perl ebuild, it is necessary to |
277 | <tr><td class="label"><a class="fn-backref" href="#id2" name="id4">[2]</a></td><td>For the purpose of readability, we will refer to 1, 2 and |
| 234 | fill in the C-library part, which on a FreeBSD system is other than |
278 | 4-tuples, even though tuple in itself suggest a field consisting of |
| 235 | on a Linux system and currently is handled as follows:</p> |
279 | two values. For clarity: a 1-tuple describes a single value field, |
| 236 | <pre class="literal-block"> |
280 | while a 4-tuple describes a field consisting out of four values.</td></tr> |
| 237 | [[ ${ELIBC} == "FreeBSD" ]] && myconf="${myconf} -Dlibc=/usr/lib/libc.a" |
|
|
| 238 | </pre> |
|
|
| 239 | </td></tr> |
|
|
| 240 | </tbody> |
281 | </tbody> |
| 241 | </table> |
282 | </table> |
| 242 | <table class="footnote" frame="void" id="id7" rules="none"> |
|
|
| 243 | <colgroup><col class="label" /><col /></colgroup> |
|
|
| 244 | <tbody valign="top"> |
|
|
| 245 | <tr><td class="label"><a class="fn-backref" href="#id3" name="id7">[3]</a></td><td>For the purpose of readability, we will refer to 1, 2 and |
|
|
| 246 | 4-tuples, even though tuple in itself suggest a field consisting of |
|
|
| 247 | two values. For clarity: a 1-tuple describes a single value field, |
|
|
| 248 | while a 4-tuple decribes a field consisting out of four values.</td></tr> |
|
|
| 249 | </tbody> |
|
|
| 250 | </table> |
|
|
| 251 | <table class="footnote" frame="void" id="id8" rules="none"> |
|
|
| 252 | <colgroup><col class="label" /><col /></colgroup> |
|
|
| 253 | <tbody valign="top"> |
|
|
| 254 | <tr><td class="label"><a class="fn-backref" href="#id4" name="id8">[4]</a></td><td><a class="reference" href="mailto:vapier">mailto:vapier</a> [at) gentoo .dot org</td></tr> |
|
|
| 255 | </tbody> |
|
|
| 256 | </table> |
|
|
| 257 | </div> |
283 | </div> |
| 258 | <div class="section" id="copyright"> |
284 | <div class="section" id="copyright"> |
| 259 | <h1><a class="toc-backref" href="#id17" name="copyright">Copyright</a></h1> |
285 | <h1><a class="toc-backref" href="#id13" name="copyright">Copyright</a></h1> |
| 260 | <p>This document has been placed in the public domain.</p> |
286 | <p>This document has been placed in the public domain.</p> |
| 261 | </div> |
287 | </div> |
| 262 | </div> |
288 | </div> |
| 263 | |
289 | |
| 264 | <hr class="footer" /> |
290 | <hr class="footer" /> |
| 265 | <div class="footer"> |
291 | <div class="footer"> |
| 266 | <a class="reference" href="glep-0047.txt">View document source</a>. |
292 | <a class="reference" href="glep-0047.txt">View document source</a>. |
| 267 | Generated on: 2006-02-09 21:32 UTC. |
293 | Generated on: 2006-02-11 21:38 UTC. |
| 268 | Generated by <a class="reference" href="http://docutils.sourceforge.net/">Docutils</a> from <a class="reference" href="http://docutils.sourceforge.net/rst.html">reStructuredText</a> source. |
294 | Generated by <a class="reference" href="http://docutils.sourceforge.net/">Docutils</a> from <a class="reference" href="http://docutils.sourceforge.net/rst.html">reStructuredText</a> source. |
| 269 | </div> |
295 | </div> |
| 270 | </body> |
296 | </body> |
| 271 | </html> |
297 | </html> |
| 272 | |
298 | |