| 1 |
mgorny 12/11/30 11:04:16 |
| 2 |
|
| 3 |
Modified: dev-guide.xml |
| 4 |
Log: |
| 5 |
Replace the Python var table with simpler tables in respective sections. Fix line breaking. |
| 6 |
|
| 7 |
Revision Changes Path |
| 8 |
1.7 xml/htdocs/proj/en/Python/python-r1/dev-guide.xml |
| 9 |
|
| 10 |
file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml?rev=1.7&view=markup |
| 11 |
plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml?rev=1.7&content-type=text/plain |
| 12 |
diff : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml?r1=1.6&r2=1.7 |
| 13 |
|
| 14 |
Index: dev-guide.xml |
| 15 |
=================================================================== |
| 16 |
RCS file: /var/cvsroot/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml,v |
| 17 |
retrieving revision 1.6 |
| 18 |
retrieving revision 1.7 |
| 19 |
diff -u -r1.6 -r1.7 |
| 20 |
--- dev-guide.xml 28 Nov 2012 19:49:28 -0000 1.6 |
| 21 |
+++ dev-guide.xml 30 Nov 2012 11:04:15 -0000 1.7 |
| 22 |
@@ -1,7 +1,7 @@ |
| 23 |
<?xml version="1.0" encoding="UTF-8"?> |
| 24 |
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd"> |
| 25 |
|
| 26 |
-<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml,v 1.6 2012/11/28 19:49:28 mgorny Exp $ --> |
| 27 |
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml,v 1.7 2012/11/30 11:04:15 mgorny Exp $ --> |
| 28 |
|
| 29 |
<guide lang="en"> |
| 30 |
<title>python-r1 Developer's Guide</title> |
| 31 |
@@ -16,7 +16,7 @@ |
| 32 |
|
| 33 |
<abstract> |
| 34 |
This guide provides a basic insight to writing ebuilds using |
| 35 |
- the python-r1 and distutils-r1 eclasses. |
| 36 |
+ the python‑r1 and distutils‑r1 eclasses. |
| 37 |
</abstract> |
| 38 |
|
| 39 |
<!-- The content of this document is licensed under the CC-BY-SA license --> |
| 40 |
@@ -34,7 +34,7 @@ |
| 41 |
|
| 42 |
<body> |
| 43 |
<p> |
| 44 |
- The new Python eclasses, python-r1 and distutils-r1, are still |
| 45 |
+ The new Python eclasses, python‑r1 and distutils‑r1, are still |
| 46 |
considered ‘testing grade’. Although they can be used |
| 47 |
in the tree, they must not be used on stable packages |
| 48 |
or packages which will need to be stabilized soon. For that |
| 49 |
@@ -114,7 +114,7 @@ |
| 50 |
|
| 51 |
<body> |
| 52 |
<p> |
| 53 |
- The python-r1 suite consists of four eclasses: |
| 54 |
+ The python‑r1 suite consists of four eclasses: |
| 55 |
</p> |
| 56 |
|
| 57 |
<ol> |
| 58 |
@@ -125,14 +125,14 @@ |
| 59 |
</ol> |
| 60 |
|
| 61 |
<p> |
| 62 |
- The <c>python-utils-r1</c> eclass is the most fundamental eclass |
| 63 |
+ The <c>python‑utils‑r1</c> eclass is the most fundamental eclass |
| 64 |
in the suite. It does not export any phase functions nor set |
| 65 |
any metadata. It does not require the package to fit |
| 66 |
any specific model. |
| 67 |
</p> |
| 68 |
|
| 69 |
<p> |
| 70 |
- The <c>python-r1</c> eclass is the second fundamental eclass. |
| 71 |
+ The <c>python‑r1</c> eclass is the second fundamental eclass. |
| 72 |
It extends the former eclass with the metadata and variables |
| 73 |
suited for packages supporting multiple Python implementations: |
| 74 |
the implementation choice flags, dependency strings. It does |
| 75 |
@@ -141,7 +141,7 @@ |
| 76 |
</p> |
| 77 |
|
| 78 |
<p> |
| 79 |
- The <c>distutils-r1</c> eclass extends python-r1 with a set |
| 80 |
+ The <c>distutils‑r1</c> eclass extends python‑r1 with a set |
| 81 |
of basic phase functions to build and install packages using |
| 82 |
the distutils build system of the inbuilt Python module |
| 83 |
<c>distutils</c>. It follows the common practices for build |
| 84 |
@@ -150,8 +150,8 @@ |
| 85 |
</p> |
| 86 |
|
| 87 |
<p> |
| 88 |
- The <c>python-single-r1</c> eclass is an alternative |
| 89 |
- to <c>python-r1</c> for packages which do not support being |
| 90 |
+ The <c>python‑single‑r1</c> eclass is an alternative |
| 91 |
+ to <c>python‑r1</c> for packages which do not support being |
| 92 |
installed for multiple Python implementations. It exports |
| 93 |
similar metadata and variables, and a <c>pkg_setup</c> phase |
| 94 |
function handling the target implementation choice. |
| 95 |
@@ -167,35 +167,35 @@ |
| 96 |
if the package supports being installed for multiple Python |
| 97 |
implementations, the Python part of it is unconditional |
| 98 |
and uses the distutils build system (or one very similar), |
| 99 |
- use the <c>distutils-r1</c> eclass; |
| 100 |
+ use the <c>distutils‑r1</c> eclass; |
| 101 |
</li> |
| 102 |
|
| 103 |
<li> |
| 104 |
if the package supports being installed for multiple Python |
| 105 |
implementations separately and installs Python modules, |
| 106 |
- scripts or embeds Python, use <c>python-r1</c>; |
| 107 |
+ scripts or embeds Python, use <c>python‑r1</c>; |
| 108 |
</li> |
| 109 |
|
| 110 |
<li> |
| 111 |
if the package can be installed for a single Python |
| 112 |
implementation only and installs Python modules, scripts |
| 113 |
- or embeds Python, use <c>python-single-r1</c>; |
| 114 |
+ or embeds Python, use <c>python‑single‑r1</c>; |
| 115 |
</li> |
| 116 |
|
| 117 |
<li> |
| 118 |
if the package has a specific or loose connection to Python, |
| 119 |
installs Python modules for multiple implementations |
| 120 |
in a common location, or has any other special needs, |
| 121 |
- consider using <c>python-utils-r1</c> (although you may |
| 122 |
+ consider using <c>python‑utils‑r1</c> (although you may |
| 123 |
not need any eclass at all). |
| 124 |
</li> |
| 125 |
</ol> |
| 126 |
|
| 127 |
<note> |
| 128 |
- Please note that the <c>distutils-r1</c> eclass inherits |
| 129 |
- <c>python-r1</c> implicitly and all the eclasses inherit |
| 130 |
- <c>python-utils-r1</c>. <c>python-r1</c> |
| 131 |
- and <c>python-single-r1</c> can not be used together. There is |
| 132 |
+ Please note that the <c>distutils‑r1</c> eclass inherits |
| 133 |
+ <c>python‑r1</c> implicitly and all the eclasses inherit |
| 134 |
+ <c>python‑utils‑r1</c>. <c>python‑r1</c> |
| 135 |
+ and <c>python‑single‑r1</c> can not be used together. There is |
| 136 |
therefore no need to ever inherit more than one eclass |
| 137 |
from the suite. |
| 138 |
</note> |
| 139 |
@@ -207,7 +207,7 @@ |
| 140 |
|
| 141 |
<body> |
| 142 |
<p> |
| 143 |
- A key concept in the workflow of python-r1 suite is the setting |
| 144 |
+ A key concept in the workflow of python‑r1 suite is the setting |
| 145 |
of the active Python interpreter. Its value is stored |
| 146 |
and exported in the <c>EPYTHON</c> environment variable. |
| 147 |
</p> |
| 148 |
@@ -243,12 +243,12 @@ |
| 149 |
</li> |
| 150 |
|
| 151 |
<li> |
| 152 |
- in implementation-specific sub-phases of <c>distutils-r1</c>, |
| 153 |
+ in implementation-specific sub-phases of <c>distutils‑r1</c>, |
| 154 |
</li> |
| 155 |
|
| 156 |
<li> |
| 157 |
- in ebuilds using the <c>python-single-r1</c> eclass after |
| 158 |
- running <c>python-single-r1_pkg_setup</c>. |
| 159 |
+ in ebuilds using the <c>python‑single‑r1</c> eclass after |
| 160 |
+ running <c>python‑single‑r1_pkg_setup</c>. |
| 161 |
</li> |
| 162 |
</ol> |
| 163 |
|
| 164 |
@@ -320,89 +320,28 @@ |
| 165 |
<title>General notes</title> |
| 166 |
|
| 167 |
<body> |
| 168 |
- <p> |
| 169 |
+ <note> |
| 170 |
The variables listed in this section apply to ebuilds using |
| 171 |
- <c>python-r1</c>, <c>distutils-r1</c> |
| 172 |
- and <c>python-single-r1</c> eclasses. |
| 173 |
- </p> |
| 174 |
- |
| 175 |
- <p> |
| 176 |
- The following table lists the differences between the values |
| 177 |
- of the metadata variables according to the inherited eclass: |
| 178 |
- </p> |
| 179 |
- |
| 180 |
- <table> |
| 181 |
- <tr> |
| 182 |
- <th>Variable</th> |
| 183 |
- <th>Common description</th> |
| 184 |
- <th>python-r1 and distutils-r1</th> |
| 185 |
- <th>python-single-r1</th> |
| 186 |
- </tr> |
| 187 |
- |
| 188 |
- <tr> |
| 189 |
- <ti><c>IUSE</c></ti> |
| 190 |
- <ti> |
| 191 |
- USE flags for selecting the interpreter. |
| 192 |
- </ti> |
| 193 |
- <ti> |
| 194 |
- <c>PYTHON_TARGETS</c> |
| 195 |
- </ti> |
| 196 |
- <ti> |
| 197 |
- <c>PYTHON_TARGETS</c> and <c>PYTHON_SINGLE_TARGET</c> |
| 198 |
- </ti> |
| 199 |
- </tr> |
| 200 |
- |
| 201 |
- <tr> |
| 202 |
- <ti><c>PYTHON_DEPS</c></ti> |
| 203 |
- <ti> |
| 204 |
- Dependencies upon Python interpreters. |
| 205 |
- </ti> |
| 206 |
- <ti> |
| 207 |
- USE-conditional upon <c>PYTHON_TARGETS</c>. |
| 208 |
- In <c>distutils-r1</c>, automatically added |
| 209 |
- to <c>RDEPEND</c> and <c>DEPEND</c>. |
| 210 |
- </ti> |
| 211 |
- <ti> |
| 212 |
- USE-conditional upon <c>PYTHON_SINGLE_TARGET</c>. |
| 213 |
- </ti> |
| 214 |
- </tr> |
| 215 |
- |
| 216 |
- <tr> |
| 217 |
- <ti><c>PYTHON_USEDEP</c></ti> |
| 218 |
- <ti> |
| 219 |
- USE-dependency string for depending on other packages. |
| 220 |
- </ti> |
| 221 |
- <ti> |
| 222 |
- Compatible with packages using <c>python-r1</c> |
| 223 |
- and <c>python-distutils-ng</c>. |
| 224 |
- </ti> |
| 225 |
- <ti> |
| 226 |
- Compatible with packages using <c>python-r1</c>, |
| 227 |
- <c>python-single-r1</c> and <c>python-distutils-ng</c>. |
| 228 |
- </ti> |
| 229 |
- </tr> |
| 230 |
- </table> |
| 231 |
- |
| 232 |
- <p> |
| 233 |
- The afore-mentioned variables are described in depth |
| 234 |
- in the sections following. |
| 235 |
- </p> |
| 236 |
+ <c>python‑r1</c>, <c>distutils‑r1</c> |
| 237 |
+ and <c>python‑single‑r1</c> eclasses. |
| 238 |
+ </note> |
| 239 |
</body> |
| 240 |
</section> |
| 241 |
|
| 242 |
<section id="pr1_Listing_supported_Python_implementations"> |
| 243 |
- <title>Listing supported Python implementations</title> |
| 244 |
+ <title>Listing supported Python implementations |
| 245 |
+ (PYTHON_COMPAT)</title> |
| 246 |
|
| 247 |
<body> |
| 248 |
<p> |
| 249 |
The first and most important task in writing ebuilds both |
| 250 |
- for python-r1 and distutils-r1 is to specify the list of Python |
| 251 |
+ for python‑r1 and distutils‑r1 is to specify the list of Python |
| 252 |
implementations supported by the ebuild. |
| 253 |
</p> |
| 254 |
|
| 255 |
<p> |
| 256 |
This list is specified using the <c>PYTHON_COMPAT</c> variable. |
| 257 |
- It is an obligatory array which has to be declared before |
| 258 |
+ It is an obligatory array which need be declared before |
| 259 |
the <c>inherit</c> command. It should list <e>all</e> supported |
| 260 |
implementations using the following naming scheme: |
| 261 |
</p> |
| 262 |
@@ -436,26 +375,26 @@ |
| 263 |
<comment># Python 2.6+ and compliant implementations.</comment> |
| 264 |
<ident>PYTHON_COMPAT</ident>=( python{2_6,2_7} pypy{1_8,1_9} ) |
| 265 |
|
| 266 |
-<comment># inherit goes below PYTHON_COMPAT</comment> |
| 267 |
+<comment># inherit follows PYTHON_COMPAT</comment> |
| 268 |
<keyword>inherit</keyword> python-r1 |
| 269 |
</pre> |
| 270 |
</body> |
| 271 |
</section> |
| 272 |
|
| 273 |
<section id="pr1_Depending_on_Python"> |
| 274 |
- <title>Depending on Python</title> |
| 275 |
+ <title>Depending on Python (PYTHON_DEPS)</title> |
| 276 |
|
| 277 |
<body> |
| 278 |
<note> |
| 279 |
Please note that this section applies to the sole use |
| 280 |
- of <c>python-r1</c> or <c>python-single-r1</c> only. |
| 281 |
- The <c>distutils-r1</c> eclass unconditionally adds this |
| 282 |
+ of <c>python‑r1</c> or <c>python‑single‑r1</c> only. |
| 283 |
+ The <c>distutils‑r1</c> eclass unconditionally adds this |
| 284 |
dependency. |
| 285 |
</note> |
| 286 |
|
| 287 |
<p> |
| 288 |
In order to efficiently handle various kinds of package |
| 289 |
- dependencies on Python, the python-r1 eclass does not set |
| 290 |
+ dependencies on Python, the python‑r1 eclass does not set |
| 291 |
the ebuild dependencies directly. Instead, it prepares |
| 292 |
the proper dependency string and stores it in a variable named |
| 293 |
<c>PYTHON_DEPS</c>. |
| 294 |
@@ -471,8 +410,8 @@ |
| 295 |
|
| 296 |
<p> |
| 297 |
The ebuild should reference the <c>PYTHON_DEPS</c> variable |
| 298 |
- in <c>RDEPEND</c> and/or <c>DEPEND</c> as necessary. It may need |
| 299 |
- to put those dependencies into an appropriate USE-conditional |
| 300 |
+ in <c>RDEPEND</c> and/or <c>DEPEND</c> as necessary. Those |
| 301 |
+ dependencies may require use of an appropriate USE-conditional |
| 302 |
block. |
| 303 |
</p> |
| 304 |
|
| 305 |
@@ -487,18 +426,57 @@ |
| 306 |
<comment># USE-conditional Python run-time dependency.</comment> |
| 307 |
<ident>RDEPEND</ident>="<const>python?</const> ( ${PYTHON_DEPS} )" |
| 308 |
</pre> |
| 309 |
+ |
| 310 |
+ <p> |
| 311 |
+ The actual value assigned to this variable differs according |
| 312 |
+ to the inherited eclass as listed in the following table: |
| 313 |
+ </p> |
| 314 |
+ |
| 315 |
+ <table> |
| 316 |
+ <tr> |
| 317 |
+ <th>Eclass</th> |
| 318 |
+ <th>Dependency type</th> |
| 319 |
+ <th>Example value</th> |
| 320 |
+ </tr> |
| 321 |
+ |
| 322 |
+ <tr> |
| 323 |
+ <ti><c>python‑r1</c> & <c>distutils‑r1</c></ti> |
| 324 |
+ <ti> |
| 325 |
+ USE-conditional upon <c>PYTHON_TARGETS</c> |
| 326 |
+ </ti> |
| 327 |
+ <ti> |
| 328 |
+ <c> |
| 329 |
+ python_targets_python2_6? ( dev-lang/python:2.6 ) |
| 330 |
+ python_targets_python2_7? ( dev-lang/python:2.7 ) |
| 331 |
+ </c> |
| 332 |
+ </ti> |
| 333 |
+ </tr> |
| 334 |
+ |
| 335 |
+ <tr> |
| 336 |
+ <ti><c>python‑single‑r1</c></ti> |
| 337 |
+ <ti> |
| 338 |
+ USE-conditional upon <c>PYTHON_SINGLE_TARGET</c> |
| 339 |
+ </ti> |
| 340 |
+ <ti> |
| 341 |
+ <c> |
| 342 |
+ python_single_target_python2_6? ( dev-lang/python:2.6 ) |
| 343 |
+ python_single_target_python2_7? ( dev-lang/python:2.7 ) |
| 344 |
+ </c> |
| 345 |
+ </ti> |
| 346 |
+ </tr> |
| 347 |
+ </table> |
| 348 |
</body> |
| 349 |
</section> |
| 350 |
|
| 351 |
<section id="pr1_Depending_on_other_Python_packages"> |
| 352 |
- <title>Depending on other Python packages</title> |
| 353 |
+ <title>Depending on other Python packages (PYTHON_USEDEP)</title> |
| 354 |
|
| 355 |
<body> |
| 356 |
<p> |
| 357 |
There are currently two kinds of Python packages in the tree; |
| 358 |
one which explicitly specify enabled Python implementations via |
| 359 |
- <c>PYTHON_TARGETS</c>, and consists of ebuilds using python-r1 |
| 360 |
- and python-distutils-ng eclasses, the other which lacks such |
| 361 |
+ <c>PYTHON_TARGETS</c>, and consists of ebuilds using python‑r1 |
| 362 |
+ and python‑distutils‑ng eclasses, the other which lacks such |
| 363 |
a support. These are packages using the ‘original’ |
| 364 |
python.eclass. |
| 365 |
</p> |
| 366 |
@@ -529,7 +507,7 @@ |
| 367 |
</p> |
| 368 |
|
| 369 |
<pre caption="Example use of PYTHON_USEDEP"> |
| 370 |
-<comment># Simple dependency on a python-r1 package.</comment> |
| 371 |
+<comment># Simple dependency on a python‑r1 package.</comment> |
| 372 |
<ident>RDEPEND</ident>="<const>dev-python/setuptools</const>[${PYTHON_USEDEP}]" |
| 373 |
|
| 374 |
<comment># Dependency with additional USE flags requested.</comment> |
| 375 |
@@ -538,11 +516,47 @@ |
| 376 |
<comment># Dependency on a package using python.eclass.</comment> |
| 377 |
<ident>RDEPEND</ident>="<const>dev-python/wxpython:2.8</const>" |
| 378 |
</pre> |
| 379 |
+ |
| 380 |
+ <p> |
| 381 |
+ The compatibility of <c>PYTHON_USEDEP</c> with ebuilds using |
| 382 |
+ different eclasses according to the inherited eclass is listed |
| 383 |
+ in the following table: |
| 384 |
+ </p> |
| 385 |
+ |
| 386 |
+ <table> |
| 387 |
+ <tr> |
| 388 |
+ <th>Eclass</th> |
| 389 |
+ <th>Compatible with</th> |
| 390 |
+ <th>Example value</th> |
| 391 |
+ </tr> |
| 392 |
+ |
| 393 |
+ <tr> |
| 394 |
+ <ti><c>python‑r1</c> & <c>distutils‑r1</c></ti> |
| 395 |
+ <ti> |
| 396 |
+ <c>python‑r1</c>, <c>python‑distutils‑ng</c> |
| 397 |
+ </ti> |
| 398 |
+ <ti> |
| 399 |
+ <c>python_targets_python2_6?,python_targets_python2_7?</c> |
| 400 |
+ </ti> |
| 401 |
+ </tr> |
| 402 |
+ |
| 403 |
+ <tr> |
| 404 |
+ <ti><c>python‑single‑r1</c></ti> |
| 405 |
+ <ti> |
| 406 |
+ <c>python‑r1</c>, |
| 407 |
+ <c>python‑single‑r1</c>, |
| 408 |
+ <c>python‑distutils‑ng</c> |
| 409 |
+ </ti> |
| 410 |
+ <ti> |
| 411 |
+ <c>python_targets_python2_6?,python_targets_python2_7?,python_single_target_python2_6(+)?,python_single_target_python2_7(+)?</c> |
| 412 |
+ </ti> |
| 413 |
+ </tr> |
| 414 |
+ </table> |
| 415 |
</body> |
| 416 |
</section> |
| 417 |
|
| 418 |
<section id="pr1_Requesting_optional_Python_features"> |
| 419 |
- <title>Requesting optional Python features (modules)</title> |
| 420 |
+ <title>Requesting optional Python features (PYTHON_REQ_USE)</title> |
| 421 |
|
| 422 |
<body> |
| 423 |
<p> |
| 424 |
@@ -600,21 +614,21 @@ |
| 425 |
</chapter> |
| 426 |
|
| 427 |
<chapter id="The_distutils_r1_eclass"> |
| 428 |
- <title>The distutils-r1 eclass</title> |
| 429 |
+ <title>The distutils‑r1 eclass</title> |
| 430 |
|
| 431 |
<section id="dr1_Tasks_performed_by_distutils_r1"> |
| 432 |
- <title>Tasks performed by distutils-r1</title> |
| 433 |
+ <title>Tasks performed by distutils‑r1</title> |
| 434 |
|
| 435 |
<body> |
| 436 |
<p> |
| 437 |
- The distutils-r1 exports a set of phase functions performing |
| 438 |
+ The distutils‑r1 exports a set of phase functions performing |
| 439 |
common tasks related to building and installing the package. |
| 440 |
In many cases, those tasks will suffice for a typical Python |
| 441 |
package. |
| 442 |
</p> |
| 443 |
|
| 444 |
<p> |
| 445 |
- The tasks performed by distutils-r1 are (in execution order): |
| 446 |
+ The tasks performed by distutils‑r1 are (in execution order): |
| 447 |
</p> |
| 448 |
|
| 449 |
<ol> |
| 450 |
@@ -657,7 +671,7 @@ |
| 451 |
|
| 452 |
<body> |
| 453 |
<p> |
| 454 |
- The distutils-r1 eclass utilises a mechanism inspired by phase |
| 455 |
+ The distutils‑r1 eclass utilises a mechanism inspired by phase |
| 456 |
functions to make writing ebuilds relatively easy. For each |
| 457 |
of the <c>src_*</c> phases, two ‘partial’ phases are used; |
| 458 |
the implementation-specific sub-phase |
| 459 |
@@ -686,11 +700,11 @@ |
| 460 |
</p> |
| 461 |
|
| 462 |
<p> |
| 463 |
- The distutils-r1 eclass provides default functions for all |
| 464 |
+ The distutils‑r1 eclass provides default functions for all |
| 465 |
implementation-specific sub-phases |
| 466 |
and for <c>python_prepare_all</c> and <c>python_install_all</c>. |
| 467 |
If you are defining any of those phase functions, you ought |
| 468 |
- call the respective distutils-r1 phase function. |
| 469 |
+ call the respective distutils‑r1 phase function. |
| 470 |
</p> |
| 471 |
|
| 472 |
<pre caption="Example of defining sub-phase functions"> |
| 473 |
@@ -718,7 +732,7 @@ |
| 474 |
|
| 475 |
<body> |
| 476 |
<p> |
| 477 |
- There are two modes of building packages with distutils-r1; |
| 478 |
+ There are two modes of building packages with distutils‑r1; |
| 479 |
‘out-of-source builds’ (the default) and ‘in-source builds’. |
| 480 |
</p> |
| 481 |
|
| 482 |
@@ -759,7 +773,7 @@ |
| 483 |
</chapter> |
| 484 |
|
| 485 |
<chapter id='Advanced_python_r1_functions'> |
| 486 |
- <title>Advanced python-r1 functions</title> |
| 487 |
+ <title>Advanced python‑r1 functions</title> |
| 488 |
|
| 489 |
<section id='pr1_Repeating_commands_for_multiple_Python_implementations'> |
| 490 |
<title>Repeating commands for multiple Python implementations</title> |
| 491 |
@@ -767,7 +781,7 @@ |
| 492 |
<body> |
| 493 |
<note> |
| 494 |
This function is mostly useful for ebuilds not using |
| 495 |
- the <c>distutils-r1</c> eclass. For those using it, placing |
| 496 |
+ the <c>distutils‑r1</c> eclass. For those using it, placing |
| 497 |
the commands in an appropriate sub-phase function is preferred. |
| 498 |
</note> |
| 499 |
|
| 500 |
@@ -846,7 +860,7 @@ |
| 501 |
</chapter> |
| 502 |
|
| 503 |
<chapter id='Helper_functions_in_python_utils_r1_eclass'> |
| 504 |
- <title>Helper functions in python-utils-r1 eclass</title> |
| 505 |
+ <title>Helper functions in python‑utils‑r1 eclass</title> |
| 506 |
|
| 507 |
<section id="pur1_General_notes"> |
| 508 |
<title>General notes</title> |
| 509 |
@@ -854,7 +868,7 @@ |
| 510 |
<body> |
| 511 |
<note> |
| 512 |
The functions listed in this section are directly available |
| 513 |
- to packages using any of the eclasses in python-r1 suite, except |
| 514 |
+ to packages using any of the eclasses in python‑r1 suite, except |
| 515 |
where noted otherwise. |
| 516 |
</note> |
| 517 |
</body> |
| 518 |
@@ -867,7 +881,7 @@ |
| 519 |
<p> |
| 520 |
Sometimes it is necessary to obtain information specific |
| 521 |
to a particular Python implementations, in particular |
| 522 |
- interpreter-specific paths. The <c>python-utils-r1</c> eclass |
| 523 |
+ interpreter-specific paths. The <c>python‑utils‑r1</c> eclass |
| 524 |
provides the following means of obtaining that information: |
| 525 |
</p> |
| 526 |
|
| 527 |
@@ -908,9 +922,9 @@ |
| 528 |
|
| 529 |
<note> |
| 530 |
The <c>python_export_best</c> function is available |
| 531 |
- in the <c>python-r1</c> eclass only. The <c>python-utils-r1</c> |
| 532 |
+ in the <c>python‑r1</c> eclass only. The <c>python‑utils‑r1</c> |
| 533 |
eclass does not trace enabled implementations, |
| 534 |
- and <c>python-single-r1</c> sets the only enabled implementation |
| 535 |
+ and <c>python‑single‑r1</c> sets the only enabled implementation |
| 536 |
as the current one, making direct <c>python_export</c> |
| 537 |
sufficient. |
| 538 |
</note> |
| 539 |
@@ -971,7 +985,7 @@ |
| 540 |
|
| 541 |
<body> |
| 542 |
<p> |
| 543 |
- The <c>python-utils-r1</c> eclass provides two major helpers |
| 544 |
+ The <c>python‑utils‑r1</c> eclass provides two major helpers |
| 545 |
which could be used to install Python scripts and modules |
| 546 |
manually. They can be used whenever the build system |
| 547 |
is not capable of installing them correctly, or the package |
Archives