1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN
"http://www.w3.org/TR/html4/loose.dtd"">
<html>
<head>
<title>Switches</title>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<meta name="GENERATOR" content="Quanta Plus">
</head>
<body>
<DIV
CLASS="NAVHEADER"
><TABLE SUMMARY="Header navigation table" WIDTH="100%" BORDER="0" CELLPADDING="0" CELLSPACING="0">
<TR><TH COLSPAN="3" ALIGN="center">Python Bindings for KDE (PyKDE-3.16.0)</TH></TR>
<TR><TD WIDTH="10%" ALIGN="left" VALIGN="bottom"><A HREF="trouble.html" ACCESSKEY="P">Prev</A></TD>
<TD WIDTH="80%" ALIGN="center" VALIGN="bottom"></TD>
<TD WIDTH="10%" ALIGN="right" VALIGN="bottom"><A HREF="examples.html" ACCESSKEY="N">Next</A></TD>
</TR>
</TABLE><HR ALIGN="LEFT" WIDTH="100%"></DIV>
<h1>configure.py Options</h1>
<p>
PyKDE builds and installs in a lot of different environments and it isn't always possible to
foresee where users or distributions will locate components that PyKDE depends on. There are
a number of command line switches used to force configure.py to look in the correct locations for
directories or files.
</p>
<table border="0" bgcolor="#E0E0E0" width="100%">
<tr>
<td>
<pre CLASS="PROGRAMLISTING">
python configure.py -h
Usage:
python configure.py [-h] [-c] [-d dir] [-g] [-j #] [-k] [-n dir] [-o dir] [-r] [-u] [-v dir] [-z file]
where:
-h displays this help message
-c concatenates each module's C/C++ source files [default]
-d dir where the PyKDE modules will be installed [default /usr/lib/python2.3/site-packages]
-g always release the GIL (SIP v3.x behaviour)
-i no concatenation of each module's C/C++ source files
-j # splits the concatenated C++ source files into # pieces [default 1]
-k dir the KDE base directory
-n dir the directory containing the KDE lib files
-o dir the directory containing the KDE header files
-r generates code with tracing enabled [default disabled]
-u build with debugging symbols
-v dir where the PyKDE .sip files will be installed [default /usr/share/sip]
-w turn on KDE deprecated object warnings when compiling [default off]
-z file the name of a file containing command line flags
If reporting errors, paste all of the output above into your
message and post to the PyKDE mailing list at:
mailto: PyKDE@mats.imk.fraunhofer.de
subscribe: http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
You can redirect the output into a file (> output.txt) if needed
</pre>
</td>
</tr>
</table>
<p>
NOTE: In the descriptions below "Default" is a "typical" value for common distributions <b>and
may not be the complete path needed</b>. You should always specify the complete path.
configure.py searches a number of locations in looking for the appropriate directories,
which may depend on the distribution used, where the version of Python used to run
configure.py is located, and other factors. For example, a default value of "python/site-packages"
could be "/usr/lib/python/site-packages", "/usr/local/python2.3/site-packages" or other values
depending on how and where Python is installed or which of several installed versions of Python
is used to run configure.py. configure.py will not try to complete the path for switch specified paths -
you <b>must</b> specifiy the complete path (eg /usr/lib/python/site-packages or ../tdecore)
</p>
<p>
For "normal" installations, configure.py will automatically discover all of the information covered by
the options below -- it is only necessary to use the options switches when configure.py can't discover
a location by itself.
</p>
<hr>
<dl>
<dt><b>-c Concatenation</b></dt>
<dd>
Building PyKDE involves loading a large number of cpp and h files. The compile process can be speeded up
considerably (by as much as 80%) by concatenating all of the cpp files into a one (or several - see -j) large
cpp file. The price for this speed up is a large increase in memory usage. By default, the feature is
'on' in configure.py. To turn this feature off, use '-i'. You may wish to turn this off if the system doing
the compile has 128MB or less RAM.
</dd>
<hr>
<dt><b>-d Installation directory</b></dt>
<dd>
<table width = "100%"><tr>
<td width = "20%"><u>Value:</u> directory path</td>
<td width = "20%"> </td>
<td width = "40%"><u>configure.py Default:</u> python/site-packages/</td>
<td width = "20%"> </td>
</tr></table>
Normally, the PyKDE modules are installed in python/site-packages. Writing to this directory retquires
root access. RPM builders sometimes need to build the modules to a different directory, or you may want
to install the modules in a different location (for example, in a subdirectory of site-packages/). For this
option to be useful, you need to ensure that Python can still locate and import the PyKDE modules from
the specified destination.
</dd>
<hr>
<dt><b>-g Always release GIL (sip 3.0 behaviour)</b></dt>
<dd>
This is a code generation option that only affects sip 4.0. It causes sip to generate C++
whose threading behavior is more like sip 3.0.
</dd>
<hr>
<dt><b>-i NO Concatenation</b></dt>
<dd>
This option causes configure.py to generate C++ code and makefiles that compile many small file
one at a time (rather than one huge file for each module). This increase compile time by about
80%, but reduces memory consumption. See -c above.
</dd>
<hr>
<dt><b>-j # of splits of concatenated files</b></dt>
<dd>
<table width = "100%"><tr>
<td width = "20%"><u>Value:</u> number of splits </td>
<td width = "20%"> </td>
<td width = "40%"><u>configure.py Default:</u> 1</td>
<td width = "20%"> </td>
</tr></table>
Intended for use on multi-CPU systems. Splits the concatenated cpp file into the specified number
of segments, each of which can be compiled concurrently in separate threads. On single processor
systems, each "split" will compile in sequence. The tdeui module is (with concatenation active)
is split into two pieces by default to reduce memory consumption. Values for 'j' greater than
2 will be honored correctly.
</dd>
<hr>
<dt><b>-k KDE base directory</b></dt>
<dd>
<table width = "100%"><tr>
<td width = "20%"><u>Value:</u> directory path</td>
<td width = "20%"> </td>
<td width = "40%"><u>configure.py Default:</u> trinity/</td>
<td width = "20%"> </td>
</tr></table>
The top level directory under which trinity/libs and trinity/include are located (these paths can also
be specified independently see -n and -o) On SuSE distributions, this is typically /opt/trinity. On
Red Hat and Mandrake, this is typically /usr. configure.py will find the typical locations automatically.
configure .py will use the KDEDIR environment variable value if it is defined and the -k switch is NOT used.
</dd>
<hr>
<dt><b>-n KDE library files</b></dt>
<dd>
<table width = "100%"><tr>
<td width = "20%"><u>Value:</u> directory path</td>
<td width = "20%"> </td>
<td width = "40%"><u>configure.py Default:</u> trinity/libs</td>
<td width = "20%"> </td>
</tr></table>
The path to KDE's library files (libtdecore.so, etc).
</dd>
<hr>
<dt><b>-o KDE h files</b></dt>
<dd>
<table width = "100%"><tr>
<td width = "20%"><u>Value:</u> directory path</td>
<td width = "20%"> </td>
<td width = "40%"><u>configure.py Default:</u> trinity/include</td>
<td width = "20%"> </td>
</tr></table>
The path to KDE's h files. (May retquire installation of tdelibs3-devel rpm package)
configure.py. PyKDE will locate h files in subdirectories of this path automatically (eg trinity/include/kio/*.h)
</dd>
<hr>
<dt><b>-r generate code with tracing enabled</b></dt>
<dd>
For debugging
</dd>
<hr>
<dt><b>-u debugging symbols</b></dt>
<dd>
For debugging
</dd>
<hr>
<dt><b>-v PyKDE sip files</b></dt>
<dd>
<table width = "100%"><tr>
<td width = "20%"><u>Value:</u> directory path</td>
<td width = "20%"> </td>
<td width = "40%"><u>configure.py Default:</u> /usr/share/sip/</td>
<td width = "20%"> </td>
</tr></table>
The path where the PyKDE sip files will be copied (for use by programs that use sip binding
dependent on PyKDE)
</dd>
<hr>
<dt><b>-w KDE deprecation warnings</b></dt>
<dd>
KDE marks a number of methods as 'deprecated'. The methods marked will generate warnings
at compile time. By default, PyKDE's configure.py turns these warnings off. -w will turn
them on.
</dd>
<hr>
<dt><b>-z Path to configure.py options file</b></dt>
<dd>
<table width = "100%"><tr>
<td width = "20%"><u>Value:</u> filename or path</td>
<td width = "20%"> </td>
<td width = "40%"><u>configure.py Default:</u> none</td>
<td width = "20%"> </td>
</tr></table>
If your site retquires the use of more than one or two option switches, you can place all of the options
in a text file and then reference only the text file's path and name on the command line. The options
are placed in the text file just as they would be on the command line, with one option per line.
For example, the options file for the command "python configure.py -c- -v /usr/local/PyTQt/sip" would look
like:
<h4><u>options.txt</u></h4>
<table border="0" bgcolor="#E0E0E0" width="100%">
<tr>
<td>
<pre CLASS="PROGRAMLISTING">
-c
-v /usr/local/PyTQt/sip
</pre>
</td>
</tr>
</table>
<p></p>
and would be run as "python configure.py -z options.txt" (assuming options.txt is in the current directory).
</dd>
<hr>
<dt><b>-l (lower case L) code gen control -- not displayed with -h</b></dt>
<dd>
If for some reason you need to rebuild a PyKDE module but not all of PyKDE, you can use -l.
-l <modulename> (eg -l tdecore) will rebuild only the module specified; -l <modulename>:
(eg -l tdecore:) will rebuild the module specified and all successive modules. If changes are
made that affect linking (especially deleting methods or other symbols), you must use the
":" form, since later modules depend on earlier modules.
</dd>
</dl>
<DIV CLASS="NAVFOOTER">
<HR ALIGN="LEFT" WIDTH="100%">
<TABLE SUMMARY="Footer navigation table" WIDTH="100%" BORDER="0" CELLPADDING="0" CELLSPACING="0" >
<TR>
<TD WIDTH="33%" ALIGN="left" VALIGN="top"><A HREF="trouble.html" ACCESSKEY="P">Prev</A></TD>
<TD WIDTH="34%" ALIGN="center" VALIGN="top"><A HREF="index.html" ACCESSKEY="H">Home</A></TD>
<TD WIDTH="33%" ALIGN="right" VALIGN="top"><A HREF="examples.html" ACCESSKEY="N">Next</A></TD>
</TR>
<TR>
<TD WIDTH="33%" ALIGN="left" VALIGN="top">Troubleshooting</TD>
<TD WIDTH="34%" ALIGN="center" VALIGN="top"> </TD>
<TD WIDTH="33%" ALIGN="right" VALIGN="top">Class Reference Documentation</TD>
</TR>
</TABLE>
</DIV>
</body>
</html>
|
