aboutsummaryrefslogtreecommitdiff
path: root/INSTALL
blob: 5d2e2259d2ca22ab860ad9dbc1969ab5b69f5f28 (plain)
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
Unless you specifically only need the build2 build system, you should install
the entire build2 toolchain instead, either using the install script
(https://build2.org/install.xhtml) or the build2-toolchain distribution.

The instructions outlined below are essentially a summary of the first three
steps of the manual bootstrap process described in build2-toolchain with a few
extra examples that would primarily be useful for distribution packaging.

Also, below we only show commands for UNIX-like operating systems. For other
operating systems and for more details on each step, refer to the
build2-toolchain installation documentation.

build2 requires a C++14 compiler. GCC 4.9, Clang 3.7, and MSVC 14 (2015) Update
3 or any later versions of these compilers are known to work. The build system
is self-hosted, which means that unless you have obtained a pre-built binary
from somewhere else, you will need to bootstrap it. To accomplish this, we use
the bootstrap.sh shell script (or equivalent batch files for Windows) found in
the root directory of the build2 distribution. On UNIX-like operating systems
as well as on Windows with MinGW or Clang, a GNU make makefile called
bootstrap.gmake can also be used with the major advanage over the script being
support for parallel compilation and an out of tree build (see comments inside
the makefile for more information).

The following is the recommended sequence of steps:

0. Prerequisites

    Get libbutl (normally from the same place where you got build2) and place
    it inside build2, so that you have:

    build2-X.Y.Z
    |
    `-- libbutl-X.Y.Z

1. Bootstrap, Phase 1

    First, we build a minimal build system using bootstrap.sh (run bootstrap.sh
    -h for options):

    $ cd build2-X.Y.Z
    $ ./bootstrap.sh g++

    $ build2/b-boot --version

    Alternatively, we can use the bootstrap.gmake makefile:

    $ cd build2-X.Y.Z
    $ make -f bootstrap.gmake -j 8 CXX=g++

    $ build2/b-boot --version

    If you would prefer to bootstrap out of source tree, this is supported by
    the makefile (but not the script):

    $ mkdir build2-boot
    $ make -C build2-boot -f ../build2-X.Y.Z/bootstrap.gmake -j 8 CXX=g++

    $ build2-boot/build2/b-boot --version

2. Bootstrap, Phase 2

    Then, we rebuild the build system with the result of Phase 1 linking
    libraries statically.

    $ build2/b-boot config.cxx=g++ config.bin.lib=static build2/exe{b}
    $ mv build2/b build2/b-boot

    $ build2/b-boot --version

    Or, alternatively, for an out of source build:

    $ build2-boot/build2/b-boot config.cxx=g++ config.bin.lib=static \
      build2-X.Y.Z/build2/@build2-static/build2/exe{b}

    $ build2-static/build2/b --version

3. Build and Install

    Finally, we configure, build, and optionally install the "final" version
    using shared libraries:

    $ build2/b-boot configure         \
      config.config.hermetic=true     \
      config.cxx=g++                  \
      config.cc.coptions=-O3          \
      config.bin.rpath=/usr/local/lib \
      config.install.root=/usr/local  \
      config.install.sudo=sudo

    $ build2/b-boot

    | The config.config.hermetic=true configuration variable in the first
    | command makes sure the embedded ~host and ~build2 configurations include
    | the current environment. This is especially important for ~build2 which
    | is used to dynamically build and load ad hoc recipes and build system
    | modules and must therefore match the environment that was used to build
    | the build system itself.

    If you are only interested in installing the result, then you can avoid
    building tests by specifying the update-for-install operation in the last
    command:

    $ build2/b-boot update-for-install

    On the other hand, if I you are not planning to install the result, then
    you can omit the config.install.* values as well as .rpath.

    To install:

    $ build2/b-boot install
    $ which b
    $ b --version

    To uninstall:

    $ b uninstall
    $ which b

    Or, alternatively, for an out of source build:

    $ build2-static/build2/b configure: build2-X.Y.Z/@build2-shared/ \
      config.config.hermetic=true     \
      config.cxx=g++                  \
      config.cc.coptions=-O3          \
      config.bin.rpath=/usr/local/lib \
      config.install.root=/usr/local  \
      config.install.sudo=sudo

    $ build2-static/build2/b update-for-install: build2-shared/

    $ build2-static/build2/b install: build2-shared/

    $ b uninstall: build2-shared/

    For distribution packaging it is often required to install "as if" into the
    system directory (for example, /usr) but to copy the files somewhere else
    (for example, /tmp/install/usr; aka the DESTDIR functionality). In build2
    this can be achieved with the config.install.chroot configuration variable,
    for example:

    $ build2-static/build2/b configure: build2-X.Y.Z/@build2-shared/ \
      config.config.hermetic=true        \
      config.cxx=g++                     \
      config.cc.coptions=-O3             \
      config.install.root=/usr           \
      config.install.chroot=/tmp/install