|
| 1 | +# Building the Metamath executable from sources |
| 2 | + |
| 3 | +## Introductionary notes |
| 4 | + |
| 5 | +In this file we describe how to build the executable metamath on a __Unix/Linux__ |
| 6 | +system from scratch using only the sources and a few auxiliary files, all |
| 7 | +distributed through the Github Metamath git repository. |
| 8 | + |
| 9 | +### Git folder of source files |
| 10 | + |
| 11 | +[Git](https://en.wikipedia.org/wiki/Git) is widespread version control system. |
| 12 | +It bundles files and subdirectories into a single folder called __repository__. |
| 13 | +Unlike a simple folder a repository tracks changes to its contents, so you can |
| 14 | +checkout older versions of a file, or different versions if multiple persons |
| 15 | +work on files simultaniously. It is out of the scope of this particular |
| 16 | +document to detail on how this system works. Instead we assume you have a |
| 17 | +fresh set of metamath source files ready in a single folder. It is of no |
| 18 | +importance here how you got it. The name of the folder is arbitrary, but for |
| 19 | +the sake of simplicity we call it throughout this file __metamath-exe__. |
| 20 | + |
| 21 | +## Unix/Linux deployment |
| 22 | + |
| 23 | +Although we restrict the build process on Unix/Linux, there exist numerous |
| 24 | +variants of this operating system (__OS__) as well as lots of flavours of |
| 25 | +installed [C](https://en.wikipedia.org/wiki/C_(programming_language) compilers. |
| 26 | +It was once a tedious task to provide a build process general enough to cope |
| 27 | +with this variety. Determining the particular properties of your OS on your |
| 28 | +computer (such as the installed libraries) was an essential first step in any |
| 29 | +build process. |
| 30 | + |
| 31 | +The situation has changed quite a bit since around 1995 when the metamath |
| 32 | +executable was designed. C meanwhile matured and was subject to a couple of |
| 33 | +standardizations like ISO/IEC 9899:1999. In effect the variety of C |
| 34 | +installations has shrunk considerably. Any modern |
| 35 | +[C99](https://en.wikipedia.org/wiki/C99) (or later) compiler along with their |
| 36 | +libraries should now compile the metamath executable out of the box. |
| 37 | + |
| 38 | +Nevertheless, from a user perspective, C programs are deployed with an |
| 39 | +installation routine comprising a configure shell script and a make file. We |
| 40 | +briefly introduce their concepts here. |
| 41 | + |
| 42 | +### configure |
| 43 | + |
| 44 | +A particular [shell script](https://en.wikipedia.org/wiki/Unix_shell) called |
| 45 | +[configure](https://en.wikipedia.org/wiki/Configure_script) tests your OS for |
| 46 | +its features. Simply determining _all_ possible properties would be extremely |
| 47 | +excessive. For example the Metamath build need not know anything about your |
| 48 | +network connections. In fact, only a tiny selection of properties need to be |
| 49 | +known. In Metamath this selection is encoded in a file __configure.h.in__. |
| 50 | +_configure_ then performs all necessary checks based on its contents and at the |
| 51 | +end issues a C header file __config.h__. This header file defines lots of |
| 52 | +C macros each reflecting a particular test result. |
| 53 | + |
| 54 | +We give an example here: |
| 55 | +In _config.h.in_ we find a line |
| 56 | +``` |
| 57 | +/* Define to 1 if stdbool.h conforms to C99. */ |
| 58 | +#undef HAVE_STDBOOL_H |
| 59 | +``` |
| 60 | +stdbool.h is a header file nowadays found in virtually every C installation. |
| 61 | +A few decades ago that was less obvious, and the system had to be checked for |
| 62 | +its existence. The shell script _configure_ carries out this check, and it has |
| 63 | +know-how built in to deal with lots of variants of both the file itself, and |
| 64 | +where to find it on a system. The test result is then issued to the _config.h_ |
| 65 | +result. Either the above is copied verbatim, or |
| 66 | +``` |
| 67 | +/* Define to 1 if stdbool.h conforms to C99. */ |
| 68 | +#define HAVE_STDBOOL_H 1 |
| 69 | +``` |
| 70 | +If the sources include this file then code alternatives can be established, as |
| 71 | +in |
| 72 | +``` |
| 73 | +#include <config.h> |
| 74 | +#if HAVE_STDBOOL_H |
| 75 | + #include <stdbool.h> |
| 76 | +#else |
| 77 | + typedef unsigned char bool; |
| 78 | +#endif |
| 79 | +``` |
| 80 | +Peculiar as it is, the Metamath executable never includes this generated file, |
| 81 | +meaning its results are prescribed anyway, and must not vary with the system |
| 82 | +(if not irreleveant). |
| 83 | + |
| 84 | +### make |
| 85 | + |
| 86 | +The _make_ program is usually part of your OS. This executable is not |
| 87 | +deployed, but the file it operates upon, the __Makefile__ is. In a nutshell, |
| 88 | +the _Makefile_ contains all information necessary to compile, link and install |
| 89 | +the Metamath executable. Besides this primary __goal__ a _Makefile_ may |
| 90 | +support others as well, such as uninstalling, generating help and so on. |
| 91 | + |
| 92 | +The Metamath makefile actually supports a plethora of _goals_, some of them |
| 93 | +have are standardized meaning, many are for partial results, not meant to be |
| 94 | +invoked by the user. |
| 95 | + |
| 96 | +The metamath executable is simple enough to be made without the support of |
| 97 | +_make_. Nevertheless, some users expect there to be a _Makefile_. If |
| 98 | +metamath happens to be part of a distribution, then a _Makefile_ is not |
| 99 | +dispensable any more. |
| 100 | + |
| 101 | +## autotools |
| 102 | + |
| 103 | +Writing any of the above files, _configure_ and _Makefile_, is all but easy, in |
| 104 | +particular in a portable way. A set of tools was written to support developers |
| 105 | +with this task. This set is called |
| 106 | +[Autotools](https://en.wikipedia.org/wiki/GNU_Autotools). The idea is to allow |
| 107 | +the developer write replacements for _configure_ and _Makefile_ in a language |
| 108 | +hiding portability issues. The necessary know-how is built into these tools |
| 109 | +and is automatically applied on translation to properly designed _configure_ |
| 110 | +and _Makefile_. From a distributors point of view the Autotools are applied as |
| 111 | +described in the following paragraphs. |
| 112 | + |
| 113 | +Executing ```autoconf --version``` shows whether you have _Autotools_ |
| 114 | +installed on your computer. |
| 115 | + |
| 116 | +### autoscan |
| 117 | + |
| 118 | +The first step is to identify all constructs subject to portability issues. |
| 119 | +_autoscan_ provides you with a suggestion in a __configure.scan__ file. |
| 120 | +This file is meant to be renamed to __autoconf.ac__, possibly extended with |
| 121 | +extra commands. In Metamath commands for strengthening compiler flags |
| 122 | +are added. |
| 123 | + |
| 124 | +### autoconf.ac |
| 125 | + |
| 126 | +This file encodes the features the OS needs to be tested for. When processed by |
| 127 | +_autoconf_ a _configure_ script along with its input file _config.h.in_ is created. |
| 128 | +Some instructions aim at replacing system dependent variables in _Makefile.am_, |
| 129 | +later used to support _make_. The language used for encoding this is __M4__ |
| 130 | +along with a couple of built-in commands of __autoconf__. This language is |
| 131 | +designed to provide cross-platform descriptions of features of the OS. |
| 132 | + |
| 133 | +### autoconf |
| 134 | + |
| 135 | +This Unix program called __autoconf__, or its sibling __autoreconf__, is |
| 136 | +capable of generating a _configure_ shell script from the input _autoconf.ac_. |
| 137 | + |
| 138 | +### Makefile.am |
| 139 | + |
| 140 | + |
| 141 | +... to be continued |
0 commit comments