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
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
|
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head> <link rel="canonical" href="http://www.mcs.anl.gov/petsc/petsc-current/docs/sphinx_docs/html/developers/buildsystem.html" />
<meta charset="utf-8" />
<title>BuildSystem — PETSc 3.14.5 documentation</title>
<link rel="stylesheet" href="../_static/sphinxdoc.css" type="text/css" />
<link rel="stylesheet" href="../_static/pygments.css" type="text/css" />
<link rel="stylesheet" type="text/css" href="../_static/graphviz.css" />
<link rel="stylesheet" type="text/css" href="https://cdn.jsdelivr.net/npm/katex@0.12.0/dist/katex.min.css" />
<link rel="stylesheet" type="text/css" href="../_static/katex-math.css" />
<script id="documentation_options" data-url_root="../" src="../_static/documentation_options.js"></script>
<script src="../_static/jquery.js"></script>
<script src="../_static/underscore.js"></script>
<script src="../_static/doctools.js"></script>
<script src="../_static/language_data.js"></script>
<script src="https://cdn.jsdelivr.net/npm/katex@0.12.0/dist/katex.min.js"></script>
<script src="https://cdn.jsdelivr.net/npm/katex@0.12.0/dist/contrib/auto-render.min.js"></script>
<script src="../_static/katex_autorenderer.js"></script>
<link rel="shortcut icon" href="../_static/PETSc_RGB-logo.png"/>
<link rel="index" title="Index" href="../genindex.html" />
<link rel="search" title="Search" href="../search.html" />
<link rel="next" title="PETSc Testing System" href="testing.html" />
<link rel="prev" title="PETSc Integration Workflows" href="integration.html" />
</head><body>
<div id="version" align=right><b>petsc-3.14.5 2021-03-03</b></div>
<div id="bugreport" align=right><a href="mailto:petsc-maint@mcs.anl.gov?subject=Typo or Error in Documentation &body=Please describe the typo or error in the documentation: petsc-3.14.5 v3.14.5 docs/sphinx_docs/html/developers/buildsystem.html "><small>Report Typos and Errors</small></a></div>
<div class="related" role="navigation" aria-label="related navigation">
<h3>Navigation</h3>
<ul>
<li class="right" style="margin-right: 10px">
<a href="../genindex.html" title="General Index"
accesskey="I">index</a></li>
<li class="right" >
<a href="testing.html" title="PETSc Testing System"
accesskey="N">next</a> |</li>
<li class="right" >
<a href="integration.html" title="PETSc Integration Workflows"
accesskey="P">previous</a> |</li>
<li class="nav-item nav-item-0"><a href="../index.html">PETSc 3.14.5 documentation</a> »</li>
<li class="nav-item nav-item-1"><a href="index.html" accesskey="U">PETSc Developer’s Documentation</a> »</li>
</ul>
</div>
<div class="sphinxsidebar" role="navigation" aria-label="main navigation">
<div class="sphinxsidebarwrapper">
<p class="logo"><a href="../index.html">
<img class="logo" src="../_static/PETSc-TAO_RGB.svg" alt="Logo"/>
</a></p>
<h3><a href="../index.html">Table of Contents</a></h3>
<ul>
<li><a class="reference internal" href="#">BuildSystem</a><ul>
<li><a class="reference internal" href="#what-is-a-build">What is a build?</a></li>
<li><a class="reference internal" href="#why-is-configure-necessary">Why is configure necessary?</a></li>
<li><a class="reference internal" href="#why-use-petsc-buildsystem">Why use PETSc BuildSystem?</a><ul>
<li><a class="reference internal" href="#namespacing">Namespacing</a></li>
<li><a class="reference internal" href="#explicit-control-flow">Explicit control flow</a></li>
<li><a class="reference internal" href="#multi-languages-tests">Multi-languages tests</a></li>
<li><a class="reference internal" href="#subpackages">Subpackages</a></li>
<li><a class="reference internal" href="#batch-environments">Batch environments</a></li>
<li><a class="reference internal" href="#caching">Caching</a></li>
<li><a class="reference internal" href="#dealing-with-errors">Dealing with Errors</a></li>
</ul>
</li>
<li><a class="reference internal" href="#high-level-organization">High level organization</a></li>
<li><a class="reference internal" href="#main-objects">Main objects</a><ul>
<li><a class="reference internal" href="#framework">Framework</a></li>
<li><a class="reference internal" href="#base">Base</a></li>
</ul>
</li>
</ul>
</li>
</ul>
<h4>Previous topic</h4>
<p class="topless"><a href="integration.html"
title="previous chapter">PETSc Integration Workflows</a></p>
<h4>Next topic</h4>
<p class="topless"><a href="testing.html"
title="next chapter">PETSc Testing System</a></p>
<div role="note" aria-label="source link">
<h3>This Page</h3>
<ul class="this-page-menu">
<li><a href="../_sources/developers/buildsystem.rst.txt"
rel="nofollow">Show Source</a></li>
</ul>
</div>
<div id="searchbox" style="display: none" role="search">
<h3 id="searchlabel">Quick search</h3>
<div class="searchformwrapper">
<form class="search" action="../search.html" method="get">
<input type="text" name="q" aria-labelledby="searchlabel" />
<input type="submit" value="Go" />
</form>
</div>
</div>
<script>$('#searchbox').show(0);</script>
</div>
</div>
<div class="document">
<div class="documentwrapper">
<div class="bodywrapper">
<div class="body" role="main">
<div class="section" id="buildsystem">
<span id="ch-buildsystem"></span><h1>BuildSystem<a class="headerlink" href="#buildsystem" title="Permalink to this headline">¶</a></h1>
<p>This chapter describes the system used by PETSc for configuration
testing, named BuildSystem. The system is written solely in Python, and
consists of a number of objects running in a coordinated fashion. Below
we describe the main objects involved, and the organization of both the
files and in-memory objects during the configure run. However, first we
discuss the configure and build process at a higher level.</p>
<div class="section" id="what-is-a-build">
<h2>What is a build?<a class="headerlink" href="#what-is-a-build" title="Permalink to this headline">¶</a></h2>
<p>The build stage compiles source to object files, stores them somehow
(usually in archives), and links shared libraries and executables. These
are mechanical operations that reduce to applying a construction rule to
sets of files. The <a class="reference external" href="http://www.gnu.org/software/make/">make</a> tool is
great at this job. However, other parts of make are not as useful, and
we should distinguish the two.</p>
<p>Make uses a single predicate, <em>older than</em>, to decide whether to apply a
rule. This is a disaster. A useful upgrade to make would expand the list
of available predicates, including things like <em>md5sum has changed</em> and
<em>flags have changed</em>. There have been attempts to use make to determine
whether a file has changed, for example by using stamp files. However,
it cannot be done without severe contortions which make it much harder
to see what make is doing and maintain the system. Right now, we can
combine make with the <a class="reference external" href="https://ccache.samba.org/">ccache</a> utility to
minimize recompiling and relinking.</p>
</div>
<div class="section" id="why-is-configure-necessary">
<h2>Why is configure necessary?<a class="headerlink" href="#why-is-configure-necessary" title="Permalink to this headline">¶</a></h2>
<p>The <em>configure</em> program is designed to assemble all information and
preconditions necessary for the build stage. This is a far more
complicated task, heavily dependent on the local hardware and software
environment. It is also the source of nearly every build problem. The
most crucial aspect of a configure system is not performance,
scalability, or even functionality, it is <em>debuggability</em>. Configuration
failure is at least as common as success, due to broken tools, operating
system upgrades, hardware incompatibilities, user error, and a host of
other reasons. Problem diagnosis is the single biggest bottleneck for
development and maintenance time. Unfortunately, current systems are
built to optimize the successful case rather than the unsuccessful. In
PETSc, we have developed the
<a href="#id1"><span class="problematic" id="id2">`</span></a>BuildSystem package
(BS) to remedy the shortcomings of configuration systems such as
Autoconf, CMake, and SCons.</p>
<p>First, BS provides consistent namespacing for tests and test results.
Tests are encapsulated in modules, which also hold the test results.
Thus you get the normal Python namespacing of results. Anyone familiar
with Autoconf will recall the painful, manual namespacing using text
prefixes inside the flat, global namespace. Also, this consistent
hierarchical organization allows external command lines to be built up
in a disciplined fashion, rather than the usual practice of dumping all
flags into global reservoirs such as the <code class="docutils literal notranslate"><span class="pre">INCLUDE</span></code> and <code class="docutils literal notranslate"><span class="pre">LIBS</span></code>
variables. This encapsulation makes it much easier to see which tests
are responsible for donating offending flags and switches when tests
fail, since errors can occur far away from the initial inclusion of a
flag.</p>
</div>
<div class="section" id="why-use-petsc-buildsystem">
<h2>Why use PETSc BuildSystem?<a class="headerlink" href="#why-use-petsc-buildsystem" title="Permalink to this headline">¶</a></h2>
<p>PETSc provides a fully functional configure model implemented in Python,
named BuildSystem (BS), which has also been used as the configuration
tool for other open sources packages. As more than a few configuration
tools currently exist, it is instructive to consider why PETSc would
choose to create another from scratch. Below we list features and design
considerations which lead us to prefer BuildSystem to the alternatives.</p>
<div class="section" id="namespacing">
<h3>Namespacing<a class="headerlink" href="#namespacing" title="Permalink to this headline">¶</a></h3>
<p>BS wraps collections of related tests in Python modules, which also hold
the test results. Thus results are accessed using normal Python
namespacing. As rudimentary as this sounds, no namespacing beyond the
use of variable name prefixes is present in SCons, CMake, or Autoconf.
Instead, a flat namespace is used, mirroring the situation in C. This
tendency appears again when composing command lines for extenral tools,
such as the compiler and linker. In the traditional configure tools,
options are aggregated in a single bucket variable, such as <code class="docutils literal notranslate"><span class="pre">INCLUDE</span></code>
or <code class="docutils literal notranslate"><span class="pre">LIBS</span></code>, whereas in BS you trace the provenance of a flag before it
is added to the command line. CMake also makes the unfortunate decision
to force all link options to resolve to full paths, which causes havoc
with compiler-private libraries.</p>
</div>
<div class="section" id="explicit-control-flow">
<h3>Explicit control flow<a class="headerlink" href="#explicit-control-flow" title="Permalink to this headline">¶</a></h3>
<p>The BS configure modules mention above, containing one configure object
per module, are organized explicitly into a directed acyclic graph
(DAG). The user indicates dependence, an <em>edge</em> in the dependence graph,
with a single call, <code class="docutils literal notranslate"><span class="pre">requires('path.to.other.test',</span> <span class="pre">self)</span></code>, which not
only structures the DAG, but returns the configure object. The caller
can then use this object to access the results of the tests run by the
dependency, achieving test and result encapsulation simply.</p>
</div>
<div class="section" id="multi-languages-tests">
<h3>Multi-languages tests<a class="headerlink" href="#multi-languages-tests" title="Permalink to this headline">¶</a></h3>
<p>BS maintains an explicit language stack, so that the current language
can be manipulated by the test environment. A compile or link can be run
using any language, complete with the proper compilers, flags,
libraries, etc with a single call. This kind of automation is crucial
for cross-language tests, which are very thinly supported in current
tools. In fact, the design of these tools inhibits this kind of check.
The <code class="docutils literal notranslate"><span class="pre">check_function_exists()</span></code> call in Autoconf and CMake looks only
for the presence of a particular symbol in a library, and fails in C++
and on Windows, whereas the equivalent BS test can also take a
declaration. The <code class="docutils literal notranslate"><span class="pre">try_compile()</span></code> test in Autoconf and CMake requires
the entire list of libraries be present in the <code class="docutils literal notranslate"><span class="pre">LIBS</span></code> variable,
providing no good way to obtain libraries from other tests in a modular
fashion. As another example, if the user has a dependent library that
requires <code class="docutils literal notranslate"><span class="pre">libstdc++</span></code>, but they are working with a C project, no
straightforward method exists to add this dependency.</p>
</div>
<div class="section" id="subpackages">
<h3>Subpackages<a class="headerlink" href="#subpackages" title="Permalink to this headline">¶</a></h3>
<p>The most complicated, but perhaps the most useful part of BS is the
support for dependent packages. It provides an object scaffolding for
including a 3rd party package (more than 60 are now available) so that
PETSc downloads, builds, and tests the package for inclusion. The native
configure and build system for the package is used, and special support
exists for GNU and CMake packages. No similar system exists in the other
tools, which rely on static declarations, such as <code class="docutils literal notranslate"><span class="pre">pkg-config</span></code> or
<code class="docutils literal notranslate"><span class="pre">FindPackage.cmake</span></code> files, that are not tested and often become
obsolete. They also require that any dependent packages use the same
configuration and build system.</p>
</div>
<div class="section" id="batch-environments">
<h3>Batch environments<a class="headerlink" href="#batch-environments" title="Permalink to this headline">¶</a></h3>
<p>Most systems, such as Autoconf and CMake, do not actually run tests in a
batch environment, but rather require a direct specification, in CMake a
“platform file”. This requires a human expert to write and maintain the
platform file. Alternatively, Buildsystem submits a dynamically
generated set of tests to the batch system, enabling automatic
cross-configuration and cross-compilation.</p>
</div>
<div class="section" id="caching">
<h3>Caching<a class="headerlink" href="#caching" title="Permalink to this headline">¶</a></h3>
<p>Caching often seems like an attractive option since configuration can be
quite time-consuming, and both Autoconf and CMake enable caching by
default. However, no system has the ability to reliably invalidate the
cache when the environment for the configuration changes. For example, a
compiler or library dependency may be upgraded on the system. Moreover,
dependencies between cached variables are not tracked, so that even if
some variables are correctly updated after an upgrade, others which
depend on them may not be. Moreover, CMake mixes together information
which is discovered automatically with that explicitly provided by the
user, which is often not tested.</p>
</div>
<div class="section" id="dealing-with-errors">
<h3>Dealing with Errors<a class="headerlink" href="#dealing-with-errors" title="Permalink to this headline">¶</a></h3>
<p>The most crucial piece of an effective configure system is good error
reporting and recovery. Most of the configuration process involves
errors, either in compiling, linking, or execution, but it can be
extremely difficult to uncover the ultimate source of an error. For
example, the configuration process might have checked the system BLAS
library, and then tried to evaluate a package that depends on BLAS such
as PETSc. It receives a link error and fails complaining about a problem
with PETSc. However, close examination of the link error shows that BLAS
with compiled without position-independent code, e.g. using the
<code class="docutils literal notranslate"><span class="pre">-fPIC</span></code> flag, but PETSc was built using the flag since it was intended
for a shared library. This is sometimes hard to detect because many
32-bit systems silently proceeed, but most 64-bit systems fail in this
case.</p>
<p>When test command lines are built up from options gleaned from many
prior tests, it is imperative that the system keep track of which tests
were responible for a given flag or a given decision in the configure
process. This failure to preserve the chain of reasoning is not unique
to configure, but is ubiquitous in software and hardware interfaces.
When your Wifi receiver fails to connect to a hub, or your cable modem
to the ISP router, you are very often not told the specific reason, but
rather given a generic error message which does not help distinguish
between the many possible failure modes. It is essential for robust
systems that error reports allow the user to track back all the way to
the decision or test which produced a given problem, although it might
involve voluminous logging. Thus the system must either be designed so
that it creates actionable diagnostics when it fails or it must have
unfailingly good support so that human intervention can resolve the
problem. The longevity of Autoconf I think can be explained by the
ability of expert users to gain access to enough information, possibly
by adding <code class="docutils literal notranslate"><span class="pre">set</span> <span class="pre">-x</span></code> to scripts and other invasive practices, to act to
resolve problems. This ability has been nearly lost in follow-on systems
such as SCons and CMake.</p>
<p>Concision is also an important attribute, as the cognitive load is
usually larger for larger code bases. The addition of logic to Autoconf
and CMake is often quite cumbersome as they do not employ a modern,
higher level language. For example, the Trilinos/TriBITS package from
Sandia National Laboratory is quite similar to PETSc in the kinds of
computations it performs. It contains 175,000 lines of CMakescript used
to configure and build the project, whereas PETSc contains less than
30,000 lines of Python code to handle configuration and regression
testing and one GNU Makefile of 130 lines.</p>
</div>
</div>
<div class="section" id="high-level-organization">
<h2>High level organization<a class="headerlink" href="#high-level-organization" title="Permalink to this headline">¶</a></h2>
<p>A minimal BuildSystem setup consists of a <code class="docutils literal notranslate"><span class="pre">config</span></code> directory off the
package root, which contains all the Python necessary run (in addition
to the BuildSystem source). At minimum, the config directory contains a
<code class="docutils literal notranslate"><span class="pre">configure.py</span></code>, which is executed to run the configure process, and a
module for the package itself. For example, PETSc contains
<code class="docutils literal notranslate"><span class="pre">config/PETSc/PETSc.py</span></code>. It is also common to include a toplevel
<code class="docutils literal notranslate"><span class="pre">configure</span></code> file to execute the configure, as this looks like
Autotools,</p>
<div class="highlight-python notranslate"><div class="highlight"><pre><span></span><span class="ch">#!/usr/bin/env python</span>
<span class="kn">import</span> <span class="nn">os</span>
<span class="n">execfile</span><span class="p">(</span><span class="n">os</span><span class="o">.</span><span class="n">path</span><span class="o">.</span><span class="n">join</span><span class="p">(</span><span class="n">os</span><span class="o">.</span><span class="n">path</span><span class="o">.</span><span class="n">dirname</span><span class="p">(</span><span class="vm">__file__</span><span class="p">),</span> <span class="s1">'config'</span><span class="p">,</span> <span class="s1">'configure.py'</span><span class="p">))</span>
</pre></div>
</div>
<p>The <code class="docutils literal notranslate"><span class="pre">configure.py</span></code> script constructs a tree of configure modules and
executes the configure process over it. A minimal version of this would
be</p>
<div class="highlight-python notranslate"><div class="highlight"><pre><span></span><span class="n">package</span> <span class="o">=</span> <span class="s1">'PETSc'</span>
<span class="k">def</span> <span class="nf">configure</span><span class="p">(</span><span class="n">configure_options</span><span class="p">):</span>
<span class="c1"># Command line arguments take precedence (but don't destroy argv[0])</span>
<span class="n">sys</span><span class="o">.</span><span class="n">argv</span> <span class="o">=</span> <span class="n">sys</span><span class="o">.</span><span class="n">argv</span><span class="p">[:</span><span class="mi">1</span><span class="p">]</span> <span class="o">+</span> <span class="n">configure_options</span> <span class="o">+</span> <span class="n">sys</span><span class="o">.</span><span class="n">argv</span><span class="p">[</span><span class="mi">1</span><span class="p">:]</span>
<span class="n">framework</span> <span class="o">=</span> <span class="n">config</span><span class="o">.</span><span class="n">framework</span><span class="o">.</span><span class="n">Framework</span><span class="p">([</span><span class="s1">'--configModules='</span><span class="o">+</span><span class="n">package</span><span class="o">+</span><span class="s1">'.Configure'</span><span class="p">,</span> <span class="s1">'--optionsModule='</span><span class="o">+</span><span class="n">package</span><span class="o">+</span><span class="s1">'.compilerOptions'</span><span class="p">]</span><span class="o">+</span><span class="n">sys</span><span class="o">.</span><span class="n">argv</span><span class="p">[</span><span class="mi">1</span><span class="p">:],</span> <span class="n">loadArgDB</span> <span class="o">=</span> <span class="mi">0</span><span class="p">)</span>
<span class="n">framework</span><span class="o">.</span><span class="n">setup</span><span class="p">()</span>
<span class="n">framework</span><span class="o">.</span><span class="n">configure</span><span class="p">(</span><span class="n">out</span> <span class="o">=</span> <span class="n">sys</span><span class="o">.</span><span class="n">stdout</span><span class="p">)</span>
<span class="n">framework</span><span class="o">.</span><span class="n">storeSubstitutions</span><span class="p">(</span><span class="n">framework</span><span class="o">.</span><span class="n">argDB</span><span class="p">)</span>
<span class="n">framework</span><span class="o">.</span><span class="n">printSummary</span><span class="p">()</span>
<span class="n">framework</span><span class="o">.</span><span class="n">argDB</span><span class="o">.</span><span class="n">save</span><span class="p">(</span><span class="n">force</span> <span class="o">=</span> <span class="kc">True</span><span class="p">)</span>
<span class="n">framework</span><span class="o">.</span><span class="n">logClear</span><span class="p">()</span>
<span class="n">framework</span><span class="o">.</span><span class="n">closeLog</span><span class="p">()</span>
<span class="k">if</span> <span class="vm">__name__</span> <span class="o">==</span> <span class="s1">'__main__'</span><span class="p">:</span>
<span class="n">configure</span><span class="p">([])</span>
</pre></div>
</div>
<p>The PETSc <code class="docutils literal notranslate"><span class="pre">configure.py</span></code> is quite a bit longer than this, but it is
doing specialized command line processing and error handling, and
integrating logging with the rest of PETSc.</p>
<p>The <code class="docutils literal notranslate"><span class="pre">config/package/Configure.py</span></code> module determines how the tree of
configure objects is built and how the configure information is output.
The <code class="docutils literal notranslate"><span class="pre">configure</span></code> method of the nodule will be run by the <code class="docutils literal notranslate"><span class="pre">framework</span></code>
object created at the top level. A minimal configure method would look
like</p>
<div class="highlight-python notranslate"><div class="highlight"><pre><span></span><span class="k">def</span> <span class="nf">configure</span><span class="p">(</span><span class="bp">self</span><span class="p">):</span>
<span class="bp">self</span><span class="o">.</span><span class="n">framework</span><span class="o">.</span><span class="n">header</span> <span class="o">=</span> <span class="bp">self</span><span class="o">.</span><span class="n">arch</span><span class="o">.</span><span class="n">arch</span><span class="o">+</span><span class="s1">'/include/'</span><span class="o">+</span><span class="bp">self</span><span class="o">.</span><span class="n">project</span><span class="o">+</span><span class="s1">'conf.h'</span>
<span class="bp">self</span><span class="o">.</span><span class="n">framework</span><span class="o">.</span><span class="n">makeMacroHeader</span> <span class="o">=</span> <span class="bp">self</span><span class="o">.</span><span class="n">arch</span><span class="o">.</span><span class="n">arch</span><span class="o">+</span><span class="s1">'/conf/'</span><span class="o">+</span><span class="bp">self</span><span class="o">.</span><span class="n">project</span><span class="o">+</span><span class="s1">'variables'</span>
<span class="bp">self</span><span class="o">.</span><span class="n">framework</span><span class="o">.</span><span class="n">makeRuleHeader</span> <span class="o">=</span> <span class="bp">self</span><span class="o">.</span><span class="n">arch</span><span class="o">.</span><span class="n">arch</span><span class="o">+</span><span class="s1">'/conf/'</span><span class="o">+</span><span class="bp">self</span><span class="o">.</span><span class="n">project</span><span class="o">+</span><span class="s1">'rules'</span>
<span class="bp">self</span><span class="o">.</span><span class="n">Dump</span><span class="p">()</span>
<span class="bp">self</span><span class="o">.</span><span class="n">logClear</span><span class="p">()</span>
<span class="k">return</span>
</pre></div>
</div>
<p>The <code class="docutils literal notranslate"><span class="pre">Dump</span></code> method runs over the tree of configure modules, and outputs
the data necessary for building, usually employing the
<code class="docutils literal notranslate"><span class="pre">addMakeMacro()</span></code>, <code class="docutils literal notranslate"><span class="pre">addMakeRule()</span></code> and <code class="docutils literal notranslate"><span class="pre">addDefine()</span></code> methods. These
method funnel output to the include and make files defined by the
framework object, and set at the beginning of this <code class="docutils literal notranslate"><span class="pre">configure()</span></code>
method. There is also some simple information that is often used, which
we define in the constructor,</p>
<div class="highlight-python notranslate"><div class="highlight"><pre><span></span><span class="k">def</span> <span class="fm">__init__</span><span class="p">(</span><span class="bp">self</span><span class="p">,</span> <span class="n">framework</span><span class="p">):</span>
<span class="n">config</span><span class="o">.</span><span class="n">base</span><span class="o">.</span><span class="n">Configure</span><span class="o">.</span><span class="fm">__init__</span><span class="p">(</span><span class="bp">self</span><span class="p">,</span> <span class="n">framework</span><span class="p">)</span>
<span class="bp">self</span><span class="o">.</span><span class="n">Project</span> <span class="o">=</span> <span class="s1">'PETSc'</span>
<span class="bp">self</span><span class="o">.</span><span class="n">project</span> <span class="o">=</span> <span class="bp">self</span><span class="o">.</span><span class="n">Project</span><span class="o">.</span><span class="n">lower</span><span class="p">()</span>
<span class="bp">self</span><span class="o">.</span><span class="n">PROJECT</span> <span class="o">=</span> <span class="bp">self</span><span class="o">.</span><span class="n">Project</span><span class="o">.</span><span class="n">upper</span><span class="p">()</span>
<span class="bp">self</span><span class="o">.</span><span class="n">headerPrefix</span> <span class="o">=</span> <span class="bp">self</span><span class="o">.</span><span class="n">PROJECT</span>
<span class="bp">self</span><span class="o">.</span><span class="n">substPrefix</span> <span class="o">=</span> <span class="bp">self</span><span class="o">.</span><span class="n">PROJECT</span>
<span class="bp">self</span><span class="o">.</span><span class="n">framework</span><span class="o">.</span><span class="n">Project</span> <span class="o">=</span> <span class="bp">self</span><span class="o">.</span><span class="n">Project</span>
<span class="k">return</span>
</pre></div>
</div>
<p>More sophisticated configure assemblies, like PETSc, output some other
custom information, such as information about the machine, configure
process, and a script to recreate the configure run.</p>
<p>The package configure module has two other main functions. First, top
level options can be defined in the <code class="docutils literal notranslate"><span class="pre">setupHelp()</span></code> method,</p>
<div class="highlight-python notranslate"><div class="highlight"><pre><span></span><span class="k">def</span> <span class="nf">setupHelp</span><span class="p">(</span><span class="bp">self</span><span class="p">,</span> <span class="n">help</span><span class="p">):</span>
<span class="kn">import</span> <span class="nn">nargs</span>
<span class="n">help</span><span class="o">.</span><span class="n">addArgument</span><span class="p">(</span><span class="bp">self</span><span class="o">.</span><span class="n">Project</span><span class="p">,</span> <span class="s1">'-prefix=<path>'</span><span class="p">,</span> <span class="n">nargs</span><span class="o">.</span><span class="n">Arg</span><span class="p">(</span><span class="kc">None</span><span class="p">,</span> <span class="s1">''</span><span class="p">,</span> <span class="s1">'Specify location to install '</span><span class="o">+</span><span class="bp">self</span><span class="o">.</span><span class="n">Project</span><span class="o">+</span><span class="s1">' (eg. /usr/local)'</span><span class="p">))</span>
<span class="n">help</span><span class="o">.</span><span class="n">addArgument</span><span class="p">(</span><span class="bp">self</span><span class="o">.</span><span class="n">Project</span><span class="p">,</span> <span class="s1">'-load-path=<path>'</span><span class="p">,</span> <span class="n">nargs</span><span class="o">.</span><span class="n">Arg</span><span class="p">(</span><span class="kc">None</span><span class="p">,</span> <span class="n">os</span><span class="o">.</span><span class="n">path</span><span class="o">.</span><span class="n">join</span><span class="p">(</span><span class="n">os</span><span class="o">.</span><span class="n">getcwd</span><span class="p">(),</span> <span class="s1">'modules'</span><span class="p">),</span> <span class="s1">'Specify location of auxiliary modules'</span><span class="p">))</span>
<span class="n">help</span><span class="o">.</span><span class="n">addArgument</span><span class="p">(</span><span class="bp">self</span><span class="o">.</span><span class="n">Project</span><span class="p">,</span> <span class="s1">'-with-shared-libraries'</span><span class="p">,</span> <span class="n">nargs</span><span class="o">.</span><span class="n">ArgBool</span><span class="p">(</span><span class="kc">None</span><span class="p">,</span> <span class="mi">0</span><span class="p">,</span> <span class="s1">'Make libraries shared'</span><span class="p">))</span>
<span class="n">help</span><span class="o">.</span><span class="n">addArgument</span><span class="p">(</span><span class="bp">self</span><span class="o">.</span><span class="n">Project</span><span class="p">,</span> <span class="s1">'-with-dynamic-loading'</span><span class="p">,</span> <span class="n">nargs</span><span class="o">.</span><span class="n">ArgBool</span><span class="p">(</span><span class="kc">None</span><span class="p">,</span> <span class="mi">0</span><span class="p">,</span> <span class="s1">'Make libraries dynamic'</span><span class="p">))</span>
<span class="k">return</span>
</pre></div>
</div>
<p>This uses the BuildSystem help facility that is used to define options
for all configure modules. The first argument groups these options into
a section named for the package. The second task is to build the tree of
modules for the configure run, using the <code class="docutils literal notranslate"><span class="pre">setupDependencies()</span></code> method.
A simple way to do this is by explicitly declaring dependencies,</p>
<div class="highlight-python notranslate"><div class="highlight"><pre><span></span><span class="k">def</span> <span class="nf">setupDependencies</span><span class="p">(</span><span class="bp">self</span><span class="p">,</span> <span class="n">framework</span><span class="p">):</span>
<span class="n">config</span><span class="o">.</span><span class="n">base</span><span class="o">.</span><span class="n">Configure</span><span class="o">.</span><span class="n">setupDependencies</span><span class="p">(</span><span class="bp">self</span><span class="p">,</span> <span class="n">framework</span><span class="p">)</span>
<span class="bp">self</span><span class="o">.</span><span class="n">setCompilers</span> <span class="o">=</span> <span class="n">framework</span><span class="o">.</span><span class="n">require</span><span class="p">(</span><span class="s1">'config.setCompilers'</span><span class="p">,</span> <span class="bp">self</span><span class="p">)</span>
<span class="bp">self</span><span class="o">.</span><span class="n">arch</span> <span class="o">=</span> <span class="n">framework</span><span class="o">.</span><span class="n">require</span><span class="p">(</span><span class="bp">self</span><span class="o">.</span><span class="n">Project</span><span class="o">+</span><span class="s1">'.utilities.arch'</span><span class="p">,</span> <span class="bp">self</span><span class="o">.</span><span class="n">setCompilers</span><span class="p">)</span>
<span class="bp">self</span><span class="o">.</span><span class="n">projectdir</span> <span class="o">=</span> <span class="n">framework</span><span class="o">.</span><span class="n">require</span><span class="p">(</span><span class="bp">self</span><span class="o">.</span><span class="n">Project</span><span class="o">+</span><span class="s1">'.utilities.projectdir'</span><span class="p">,</span> <span class="bp">self</span><span class="o">.</span><span class="n">arch</span><span class="p">)</span>
<span class="bp">self</span><span class="o">.</span><span class="n">compilers</span> <span class="o">=</span> <span class="n">framework</span><span class="o">.</span><span class="n">require</span><span class="p">(</span><span class="s1">'config.compilers'</span><span class="p">,</span> <span class="bp">self</span><span class="p">)</span>
<span class="bp">self</span><span class="o">.</span><span class="n">types</span> <span class="o">=</span> <span class="n">framework</span><span class="o">.</span><span class="n">require</span><span class="p">(</span><span class="s1">'config.types'</span><span class="p">,</span> <span class="bp">self</span><span class="p">)</span>
<span class="bp">self</span><span class="o">.</span><span class="n">headers</span> <span class="o">=</span> <span class="n">framework</span><span class="o">.</span><span class="n">require</span><span class="p">(</span><span class="s1">'config.headers'</span><span class="p">,</span> <span class="bp">self</span><span class="p">)</span>
<span class="bp">self</span><span class="o">.</span><span class="n">functions</span> <span class="o">=</span> <span class="n">framework</span><span class="o">.</span><span class="n">require</span><span class="p">(</span><span class="s1">'config.functions'</span><span class="p">,</span> <span class="bp">self</span><span class="p">)</span>
<span class="bp">self</span><span class="o">.</span><span class="n">libraries</span> <span class="o">=</span> <span class="n">framework</span><span class="o">.</span><span class="n">require</span><span class="p">(</span><span class="s1">'config.libraries'</span><span class="p">,</span> <span class="bp">self</span><span class="p">)</span>
<span class="bp">self</span><span class="o">.</span><span class="n">compilers</span><span class="o">.</span><span class="n">headerPrefix</span> <span class="o">=</span> <span class="bp">self</span><span class="o">.</span><span class="n">headerPrefix</span>
<span class="bp">self</span><span class="o">.</span><span class="n">types</span><span class="o">.</span><span class="n">headerPrefix</span> <span class="o">=</span> <span class="bp">self</span><span class="o">.</span><span class="n">headerPrefix</span>
<span class="bp">self</span><span class="o">.</span><span class="n">headers</span><span class="o">.</span><span class="n">headerPrefix</span> <span class="o">=</span> <span class="bp">self</span><span class="o">.</span><span class="n">headerPrefix</span>
<span class="bp">self</span><span class="o">.</span><span class="n">functions</span><span class="o">.</span><span class="n">headerPrefix</span> <span class="o">=</span> <span class="bp">self</span><span class="o">.</span><span class="n">headerPrefix</span>
<span class="bp">self</span><span class="o">.</span><span class="n">libraries</span><span class="o">.</span><span class="n">headerPrefix</span> <span class="o">=</span> <span class="bp">self</span><span class="o">.</span><span class="n">headerPrefix</span>
</pre></div>
</div>
<p>The <code class="docutils literal notranslate"><span class="pre">projectdir</span></code> and <code class="docutils literal notranslate"><span class="pre">arch</span></code> modules define the project root
directory and a build name so that multiple independent builds can be
managed. The <code class="docutils literal notranslate"><span class="pre">Framework.require()</span></code> method creates an edge in the
dependence graph for configure modules, and returns the module object so
that it can be queried after the configure information is determined.
Setting the header prefix routes all the defines made inside those
modules to our package configure header. We can also automatically
create configure modules based upon what we see on the filesystem,</p>
<div class="highlight-python notranslate"><div class="highlight"><pre><span></span><span class="k">for</span> <span class="n">utility</span> <span class="ow">in</span> <span class="n">os</span><span class="o">.</span><span class="n">listdir</span><span class="p">(</span><span class="n">os</span><span class="o">.</span><span class="n">path</span><span class="o">.</span><span class="n">join</span><span class="p">(</span><span class="s1">'config'</span><span class="p">,</span> <span class="bp">self</span><span class="o">.</span><span class="n">Project</span><span class="p">,</span> <span class="s1">'utilities'</span><span class="p">)):</span>
<span class="p">(</span><span class="n">utilityName</span><span class="p">,</span> <span class="n">ext</span><span class="p">)</span> <span class="o">=</span> <span class="n">os</span><span class="o">.</span><span class="n">path</span><span class="o">.</span><span class="n">splitext</span><span class="p">(</span><span class="n">utility</span><span class="p">)</span>
<span class="k">if</span> <span class="ow">not</span> <span class="n">utilityName</span><span class="o">.</span><span class="n">startswith</span><span class="p">(</span><span class="s1">'.'</span><span class="p">)</span> <span class="ow">and</span> <span class="ow">not</span> <span class="n">utilityName</span><span class="o">.</span><span class="n">startswith</span><span class="p">(</span><span class="s1">'#'</span><span class="p">)</span> <span class="ow">and</span> <span class="n">ext</span> <span class="o">==</span> <span class="s1">'.py'</span> <span class="ow">and</span> <span class="ow">not</span> <span class="n">utilityName</span> <span class="o">==</span> <span class="s1">'__init__'</span><span class="p">:</span>
<span class="n">utilityObj</span> <span class="o">=</span> <span class="bp">self</span><span class="o">.</span><span class="n">framework</span><span class="o">.</span><span class="n">require</span><span class="p">(</span><span class="bp">self</span><span class="o">.</span><span class="n">Project</span><span class="o">+</span><span class="s1">'.utilities.'</span><span class="o">+</span><span class="n">utilityName</span><span class="p">,</span> <span class="bp">self</span><span class="p">)</span>
<span class="n">utilityObj</span><span class="o">.</span><span class="n">headerPrefix</span> <span class="o">=</span> <span class="bp">self</span><span class="o">.</span><span class="n">headerPrefix</span>
<span class="n">utilityObj</span><span class="o">.</span><span class="n">archProvider</span> <span class="o">=</span> <span class="bp">self</span><span class="o">.</span><span class="n">arch</span>
<span class="n">utilityObj</span><span class="o">.</span><span class="n">languageProvider</span> <span class="o">=</span> <span class="bp">self</span><span class="o">.</span><span class="n">languages</span>
<span class="n">utilityObj</span><span class="o">.</span><span class="n">precisionProvider</span> <span class="o">=</span> <span class="bp">self</span><span class="o">.</span><span class="n">scalartypes</span>
<span class="n">utilityObj</span><span class="o">.</span><span class="n">installDirProvider</span> <span class="o">=</span> <span class="bp">self</span><span class="o">.</span><span class="n">installdir</span>
<span class="n">utilityObj</span><span class="o">.</span><span class="n">externalPackagesDirProvider</span> <span class="o">=</span> <span class="bp">self</span><span class="o">.</span><span class="n">externalpackagesdir</span>
<span class="nb">setattr</span><span class="p">(</span><span class="bp">self</span><span class="p">,</span> <span class="n">utilityName</span><span class="o">.</span><span class="n">lower</span><span class="p">(),</span> <span class="n">utilityObj</span><span class="p">)</span>
</pre></div>
</div>
<p>The provider modules customize the information given to the module based
upon settings for our package. For example, PETSc can be compiled with a
scalar type that is single, double, or quad precision, and thus has a
<code class="docutils literal notranslate"><span class="pre">precisionProvider</span></code>. If a package does not have this capability, the
provider setting can be omitted.</p>
</div>
<div class="section" id="main-objects">
<h2>Main objects<a class="headerlink" href="#main-objects" title="Permalink to this headline">¶</a></h2>
<div class="section" id="framework">
<h3>Framework<a class="headerlink" href="#framework" title="Permalink to this headline">¶</a></h3>
<p>The <code class="docutils literal notranslate"><span class="pre">config.framework.Framework</span></code> object serves as the central control
for a configure run. It maintains a graph of all the configure modules
involved, which is also used to track dependencies between them. It
initiates the run, compiles the results, and handles the final output.
It maintains the help list for all options available in the run. The
<code class="docutils literal notranslate"><span class="pre">setup()</span></code> method preforms generic <code class="docutils literal notranslate"><span class="pre">Script</span></code> setup and then is called
recursively on all the child modules. The <code class="docutils literal notranslate"><span class="pre">cleanup()</span></code> method performs
the final output and logging actions,</p>
<ul class="simple">
<li><p>Subtitute files</p></li>
<li><p>Output configure header</p></li>
<li><p>Log filesystem actions</p></li>
</ul>
<p>Children may be added to the Framework using <code class="docutils literal notranslate"><span class="pre">addChild()</span></code> or
<code class="docutils literal notranslate"><span class="pre">getChild()</span></code>, but the far more frequent method is to use
<code class="docutils literal notranslate"><span class="pre">require()</span></code>. Here a module is requested, as in <code class="docutils literal notranslate"><span class="pre">getChild()</span></code>, but it
is also required to run before another module, usually the one executing
the <code class="docutils literal notranslate"><span class="pre">require()</span></code>. This provides a simple local interface to establish
dependencies between the child modules, and provides a partial order on
the children to the Framework.</p>
<p>A backwards compatibility mode is provided for which the user specifies
a configure header and set of files to experience substitution,
mirroring the common usage of Autoconf. Slight improvements have been
made in that all defines are now guarded, various prefixes are allowed
for defines and substitutions, and C specific constructs such as
function prototypes and typedefs are removed to a separate header.
However, this is not the intended future usage. The use of configure
modules by other modules in the same run provides a model for the
suggested interaction of a new build system with the Framework. If a
module requires another, it merely executes a <code class="docutils literal notranslate"><span class="pre">require()</span></code>. For
instance, the PETSc configure module for HYPRE requires information
about MPI, and thus contains</p>
<div class="highlight-c notranslate"><div class="highlight"><pre><span></span><span class="n">self</span><span class="p">.</span><span class="n">mpi</span> <span class="o">=</span> <span class="n">self</span><span class="p">.</span><span class="n">framework</span><span class="p">.</span><span class="n">require</span><span class="p">(</span><span class="s">"config.packages.MPI"</span><span class="p">,</span> <span class="n">self</span><span class="p">)</span>
</pre></div>
</div>
<p>Notice that passing self for the last arguments means that the MPI
module will run before the HYPRE module. Furthermore, we save the
resulting object as <code class="docutils literal notranslate"><span class="pre">self.mpi</span></code> so that we may interogate it later.
HYPRE can initially test whether MPI was indeed found using
<code class="docutils literal notranslate"><span class="pre">self.mpi.found</span></code>. When HYPRE requires the list of MPI libraries in
order to link a test object, the module can use <code class="docutils literal notranslate"><span class="pre">self.mpi.lib</span></code>.</p>
</div>
<div class="section" id="base">
<h3>Base<a class="headerlink" href="#base" title="Permalink to this headline">¶</a></h3>
<p>The <code class="docutils literal notranslate"><span class="pre">config.base.Configure</span></code> is the base class for all configure
objects. It handles several types of interaction. First, it has hooks
that allow the Framework to initialize it correctly. The Framework will
first instantiate the object and call <code class="docutils literal notranslate"><span class="pre">setupDependencies()</span></code>. All
<code class="docutils literal notranslate"><span class="pre">require()</span></code> calls should be made in that method. The Framework will
then call <code class="docutils literal notranslate"><span class="pre">configure()</span></code>. If it succeeds, the object will be marked as
configured. Second, all configure tests should be run using
<code class="docutils literal notranslate"><span class="pre">executeTest()</span></code> which formats the output and adds metadata for the
log.</p>
<p>Third, all tests that involve preprocessing, compiling, linking, and
running operator through <code class="docutils literal notranslate"><span class="pre">base</span></code>. Two forms of this check are provided
for each operation. The first is an “output” form which is intended to
provide the status and complete output of the command. The second, or
“check” form will return a success or failure indication based upon the
status and output. The routines are</p>
<div class="highlight-python notranslate"><div class="highlight"><pre><span></span><span class="n">outputPreprocess</span><span class="p">(),</span> <span class="n">checkPreprocess</span><span class="p">(),</span> <span class="n">preprocess</span><span class="p">()</span>
<span class="n">outputCompile</span><span class="p">(),</span> <span class="n">checkCompile</span><span class="p">()</span>
<span class="n">outputLink</span><span class="p">(),</span> <span class="n">checkLink</span><span class="p">()</span>
<span class="n">outputRun</span><span class="p">(),</span> <span class="n">checkRun</span><span class="p">()</span>
</pre></div>
</div>
<p>The language used for these operation is managed with a stack, similar
to autoconf, using <code class="docutils literal notranslate"><span class="pre">pushLanguage()</span></code> and <code class="docutils literal notranslate"><span class="pre">popLanguage()</span></code>. We also
provide special forms used to check for valid compiler and linker flags,
optionally adding them to the defaults.</p>
<div class="highlight-python notranslate"><div class="highlight"><pre><span></span><span class="n">checkCompilerFlag</span><span class="p">(),</span> <span class="n">addCompilerFlag</span><span class="p">()</span>
<span class="n">checkLinkerFlag</span><span class="p">(),</span> <span class="n">addLinkerFlag</span><span class="p">()</span>
</pre></div>
</div>
<p>You can also use <code class="docutils literal notranslate"><span class="pre">getExecutable()</span></code> to search for executables.</p>
<p>After configure tests have been run, various kinds of output can be
generated.A #define statement can be added to the configure header using
<code class="docutils literal notranslate"><span class="pre">addDefine()</span></code>, and <code class="docutils literal notranslate"><span class="pre">addTypedef()</span></code> and <code class="docutils literal notranslate"><span class="pre">addPrototype()</span></code> also put
information in this header file. Using <code class="docutils literal notranslate"><span class="pre">addMakeMacro()</span></code> and
<code class="docutils literal notranslate"><span class="pre">addMakeRule()</span></code> will add make macros and rules to the output makefiles
specified in the framework. In addition we provide <code class="docutils literal notranslate"><span class="pre">addSubstitution()</span></code>
and <code class="docutils literal notranslate"><span class="pre">addArgumentSubstitution()</span></code> to mimic the bahvior of Autoconf if
necessary. The object may define a <code class="docutils literal notranslate"><span class="pre">headerPrefix</span></code> member, which will
be appended, followed by an underscore, to every define which is output
from it. Similarly, a <code class="docutils literal notranslate"><span class="pre">substPrefix</span></code> can be defined which applies to
every substitution from the object. Typedefs and function prototypes are
placed in a separate header in order to accommodate languages such as
Fortran whose preprocessor can sometimes fail at these statements.</p>
</div>
</div>
</div>
</div>
</div>
</div>
<div class="clearer"></div>
</div>
<div class="related" role="navigation" aria-label="related navigation">
<h3>Navigation</h3>
<ul>
<li class="right" style="margin-right: 10px">
<a href="../genindex.html" title="General Index"
>index</a></li>
<li class="right" >
<a href="testing.html" title="PETSc Testing System"
>next</a> |</li>
<li class="right" >
<a href="integration.html" title="PETSc Integration Workflows"
>previous</a> |</li>
<li class="nav-item nav-item-0"><a href="../index.html">PETSc 3.14.5 documentation</a> »</li>
<li class="nav-item nav-item-1"><a href="index.html" >PETSc Developer’s Documentation</a> »</li>
</ul>
</div>
<div class="footer" role="contentinfo">
© Copyright 1991-2021, UChicago Argonne, LLC and the PETSc Development Team.
Created using <a href="http://sphinx-doc.org/">Sphinx</a> 2.4.4.
</div>
</body>
</html>
|
