-
Notifications
You must be signed in to change notification settings - Fork 54
/
README.bootstrap
100 lines (82 loc) · 4.24 KB
/
README.bootstrap
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
INTRODUCTION
============
Michael T. Richter <ttmrichter@gmail.com>
This document explains the process of bootstrapping a Mercury environment from
the Git repository.
PREREQUISITES
-------------
If you do not have a Mercury environment already set up on your system, you
cannot build the Mercury compiler from revision control, full stop. Mercury,
like almost every other self-hosted natively-compiled language, needs itself to
compile itself. To accomplish this you will have to build one of the releases:
either a numbered release (like, say, 11.07.2) or one of the ROTD releases. For
purposes of bootstrapping from the master branch of the Git repository it is
recommended to start with the most recent ROTD release since older versions of
the Mercury compiler are frequently not able to build the bleeding edge in Git.
The releases can be downloaded from the Mercury website's downloads page:
https://dl.mercurylang.org/index.html.
Other prerequisites can be found in relevant README.* files in the
distribution's root directory.
BUILDING THE PREREQUISITE RELEASE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
By default the Mercury distribution builds a number and variety of "grades"
(c.f. the user guide). Building numerous grades is overkill for purposes of
bootstrapping. After downloading and expanding the selected prerequisite, the
following command sequence should be issued:
----
./configure --enable-minimal-install
make
sudo make install
----
This will do the minimal build necessary to have a usable Mercury compiler for
bootstrapping. Note that once this prerequisite release is built, there is no
further need for tarballs when building Mercury from Git.
BOOTSTRAPPING
-------------
Once the minimal prerequisite compiler has been built and installed, a
reasonably complete distribution can be bootstrapped. However the build
tree must be clean or the build may fail. Clean and then build the complete
distribution by issuing the following command sequence:
----
make realclean
./prepare.sh
./configure
make
sudo make install
----
This, however, will take a surprisingly long time by most prospective users'
standards. (In particular the `make install` phase will take a very long time.)
This is because, as mentioned above, Mercury compiles its standard library in a
number of grades. The number of grades, and therefore build time, can be
reduced by using the configure script's `--enable-libgrades=<grade list>`
option, where <grade list> is a comma separated list of grades. For information
about which grades may be relevant, see the documentation on grades and grade
components:
https://www.mercurylang.org/information/doc-latest/mercury_user_guide/Grades-and-grade-components.html
People wanting to simply experiment with Mercury would be best-served with
using only the `asm_fast.gc` grade or `hlc.gc` on OS X.
Since building Mercury can take a long time, you may prefer to use multiple
processors during the build process. Adding "PARALLEL=-jN" without the
quotes to make's command line will tell make to run N tasks at once.
Substitute N with the number of processors in your system, or fewer if you
want to use other processors for other tasks. For example:
----
make PARALLEL=-j4
sudo make PARALLEL=-j4 install
----
ALTERNATIVES TO BOOTSTRAPPING
-----------------------------
Unless you are planning to contribute to the Mercury project, bootstrapping
from the SCM head is likely not a desired approach. For just experimenting
with and/or learning the language the best approach is to either download one
of the stable (numbered, like 11.07.2) releases or, if you want to experiment
with the latest and greatest features, one of the more recent ROTD releases.
Doing this eliminates the need to build the compiler twice since a full build
and install can be done directly from the tarballs.
One possible reason to go through a bootstrap (or at least through a quick
`asm_fast.gc` build followed by a more complete build) is that on 64-bit
systems in specific, a bootstrapped compiler is very slightly faster than one
built once from the tarballs. This is because the tarballs must be compatible
with both 32- and 64-bit systems while a bootstrapped system can take advantage
of 64-bit specific enhancements.
We strongly recommend the use of the `hlc.gc` grade on OS X (See README.macOS.md).