| 1 |
mgorny 12/11/27 17:47:42 |
| 2 |
|
| 3 |
Modified: dev-guide.xml |
| 4 |
Log: |
| 5 |
Clean up the in-source build description, minor fixes. |
| 6 |
|
| 7 |
Revision Changes Path |
| 8 |
1.4 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.4&view=markup |
| 11 |
plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml?rev=1.4&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.3&r2=1.4 |
| 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.3 |
| 18 |
retrieving revision 1.4 |
| 19 |
diff -u -r1.3 -r1.4 |
| 20 |
--- dev-guide.xml 26 Nov 2012 12:14:31 -0000 1.3 |
| 21 |
+++ dev-guide.xml 27 Nov 2012 17:47:42 -0000 1.4 |
| 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.3 2012/11/26 12:14:31 mgorny Exp $ --> |
| 27 |
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/Python/python-r1/dev-guide.xml,v 1.4 2012/11/27 17:47:42 mgorny Exp $ --> |
| 28 |
|
| 29 |
<guide lang="en"> |
| 30 |
<title>python-r1 Developer's Guide</title> |
| 31 |
@@ -23,8 +23,8 @@ |
| 32 |
<!-- See http://creativecommons.org/licenses/by-sa/3.0/ --> |
| 33 |
<license version="3.0"/> |
| 34 |
|
| 35 |
-<version>3</version> |
| 36 |
-<date>2012-11-26</date> |
| 37 |
+<version>4</version> |
| 38 |
+<date>2012-11-27</date> |
| 39 |
|
| 40 |
<chapter id="Introductory_info"> |
| 41 |
<title>Introductory information</title> |
| 42 |
@@ -547,21 +547,23 @@ |
| 43 |
<p> |
| 44 |
There are two modes of building packages with distutils-r1; |
| 45 |
‘out-of-source builds’ (the default) and ‘in-source builds’. |
| 46 |
- An out-of-source build uses a common source directory, reads |
| 47 |
- files from that directory but locates the built files |
| 48 |
- in a separate directory. An in-source build locates both |
| 49 |
- the source and output files in the same directory. |
| 50 |
</p> |
| 51 |
|
| 52 |
<p> |
| 53 |
- When an out-of-source build is used, the phase functions are run |
| 54 |
- in the <c>${S}</c> directory. The build directory used |
| 55 |
- for the particular implementation is stored |
| 56 |
- in the <c>BUILD_DIR</c> variable, all calls to <c>setup.py</c> |
| 57 |
- pass additional <c>build --build-base…</c> parameters pointing |
| 58 |
- to it and the <path>lib</path> subdirectory of the build |
| 59 |
- directory is added to <c>PYTHONPATH</c>. As a consequence, |
| 60 |
- the package is built on the first <c>setup.py</c> invocation. |
| 61 |
+ When an out-of-source build is performed, the build directory |
| 62 |
+ (<c>${BUILD_DIR}</c>) is used to store output files, while |
| 63 |
+ the sources are kept in their original location. Therefore, |
| 64 |
+ the build system must not attempt to modify any of the input |
| 65 |
+ files or write to <c>${S}</c>. |
| 66 |
+ </p> |
| 67 |
+ |
| 68 |
+ <p> |
| 69 |
+ In order to support out-of-source builds, the build directory |
| 70 |
+ is appended to <c>PYTHONPATH</c> and <c>esetup.py</c> command |
| 71 |
+ adds build directory paths to the <c>setup.py</c> invocation. |
| 72 |
+ Due to technical limitations of distutils, this results |
| 73 |
+ in the package being built on the first <c>esetup.py</c> |
| 74 |
+ invocation. |
| 75 |
</p> |
| 76 |
|
| 77 |
<p> |
| 78 |
@@ -573,15 +575,11 @@ |
| 79 |
</p> |
| 80 |
|
| 81 |
<p> |
| 82 |
- When in-source builds are enabled, the default |
| 83 |
- <c>python_prepare_all</c> first creates a copy of all |
| 84 |
- the sources in the <c>BUILD_DIR</c> for each implementation. |
| 85 |
- The implementation-common sub-phase functions are still executed |
| 86 |
- in the source directory, but those |
| 87 |
- of the implementation-specific sub-phases are executed in build |
| 88 |
- directories. There is no explicit linking between the source |
| 89 |
- copies, therefore the build system is allowed to modify them |
| 90 |
- freely. |
| 91 |
+ When an in-source build is performed, the build directory acts |
| 92 |
+ both as a source and output directory. The package sources |
| 93 |
+ are copied there first, and all implementation-specific |
| 94 |
+ sub-phases are executed in the build directory. Therefore, |
| 95 |
+ the build system is allowed to modify the sources freely. |
| 96 |
</p> |
| 97 |
</body> |
| 98 |
</section> |
| 99 |
@@ -603,7 +601,7 @@ |
| 100 |
<p> |
| 101 |
If it is necessary to run a command repeatedly for multiple |
| 102 |
Python implementations, the <c>python_foreach_impl</c> function |
| 103 |
- can be used. It takes a command and a list of its paraameters/, |
| 104 |
+ can be used. It takes a command and a list of its parameters |
| 105 |
and runs it once for each Python implementation enabled. |
| 106 |
The command can also name a local function. |
| 107 |
</p> |
| 108 |
@@ -750,7 +748,8 @@ |
| 109 |
to standard output. The output can be captured using bash |
| 110 |
command substitution. These functions take an optional parameter |
| 111 |
specifying the requested Python implementation. |
| 112 |
- If not specified, the current one will be used. |
| 113 |
+ If not specified, the implementation set as <c>EPYTHON</c> will |
| 114 |
+ be used. |
| 115 |
</p> |
| 116 |
|
| 117 |
<p> |
Archives