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
|
// file : UPGRADE.cli
// copyright : Copyright (c) 2014-2016 Code Synthesis Ltd
// license : MIT; see accompanying LICENSE file
"
At this point we assume that you have the build2 toolchain installed and would
like to upgrade it to a newer version. We also expect that you have the
toolchain \c{bpkg} configuration in the \c{build2-toolchain} directory, as
produced by the bootstrap process. If you don't have the \c{bpkg}
configuration but do have the toolchain installed somehow (for example, using
your distribution's package manager), then you can create one as shown at the
end. If you have neither, then you will need to go through the bootstrap
process.
There are two ways to upgrade: dirty (but quick) and staged (but more involved). In
the \i{dirty upgrade} we override the existing installation without first
uninstalling it. If some installed files no longer exist in the new version,
they will remain \"installed\" until cleaned up manually. Also, with this
approach we never get a chance to make sure the new build is functional.
In the \i{staged upgrade} we first install a \c{-stage} build of the new
toolchain (similar to what we did during bootstrap), test it, uninstall the
old toolchain, install the new toolchain as non-staged, and finally uninstall
the \c{-stage} installation.
We recommend that you use a dirty upgrade for a bugfix-only release (the same
\c{MAJOR.MINOR} version) and a staged upgrade otherwise. With bugfix-only
releases we guarantee not to alter the installation file set. Note also that
without periodic upgrades your version of the toolchain may become too old to
be able to upgrade itself. In this case you will have to fall back onto the
bootstrap process.
The dirty upgrade is fairly simple:
\
$ cd build2-toolchain
$ bpkg fetch
$ bpkg build build2 bpkg
$ bpkg install build2 bpkg
\
You may also want to issue the \c{status} command after \c{fetch} to examine
which versions are available. By default \c{bpkg} will upgrade to the latest
available but you can override this by specifying the desired version
explicitly, for example:
\
$ bpkg status build2 bpkg
build2: configured 1.0.0; available 1.0.1 2.0.0
bpkg: configured 1.0.0; available 1.0.1 2.0.0
$ bpkg build build2/1.0.1 bpkg/1.0.1
\
The staged upgrade consists of several steps:
\dl|
\li|1. Save Old Configuration\n
First we make a copy of the old configuration. We will need it later to
cleanly uninstall the old toolchain.
\
$ rm -r build2-toolchain-old
$ cp -rp build2-toolchain build2-toolchain-old
\
Or, using Windows command prompt:
\
> rmdir /s /q build2-toolchain-old
> xcopy /s /q /i build2-toolchain build2-toolchain-old
\
|
\li|\n2. Build and Install as \c{-stage}\n
This step is similar to the dirty upgrade except we install the toolchain with
the \c{-stage} suffix.
\
$ cd build2-toolchain
$ bpkg fetch
$ bpkg build build2 bpkg
$ bpkg install \
config.bin.suffix=-stage \
config.install.data_root=root/stage \
build2 bpkg
\
|
\li|\n3. Test Staged\n
Now you can optionally test the new toolchain on your projects, etc. Remember
to use the \c{-stage}-suffixed binaries (\c{bpkg-stage} will automatically use
\c{b-stage}):
\
$ b-stage --version
$ bpkg-stage --version
\
|
\li|\n4. Uninstall Old, Install New\n
Once we are satisfied the new toolchain works, we can uninstall the old
one and install the new:
\
$ cd ../build2-toolchain-old
$ bpkg uninstall build2 bpkg
$ cd ../build2-toolchain
$ bpkg-stage install build2 bpkg
\
|
\li|\n5. Uninstall Staged\n
Finally we clean up by removing the staged toolchain (hint: use command line
history to find the corresponding \cb{install} command change it to
uninstall):
\
$ bpkg uninstall \
config.bin.suffix=-stage \
config.install.data_root=root/stage \
build2 bpkg
\
||
If you ever need to (re-)create the \c{bpkg} configuration for the toolchain
from scratch, it is fairly simple (you may need to adjust the compiler,
options, installation directory, etc):
For UNIX-like operating systems (GNU/Linux, Mac OS X, FreeBSD, etc):
\
$ bpkg-stage create \
cc \
config.cxx=g++ \
config.cc.coptions=-O3 \
config.bin.lib=shared \
config.bin.rpath=/usr/local/lib \
config.install.root=/usr/local \
config.install.sudo=sudo
\
For Windows with MSVC (from the Visual Studio command prompt):
\
> bpkg-stage create ^
cc ^
config.cxx=cl ^
\"config.cc.coptions=/O2 /Oi\" ^
config.bin.lib=shared ^
config.install.root=C:\build2
\
For Windows with MinGW (from the command prompt):
\
> bpkg-stage create ^
cc ^
config.cxx=g++ ^
config.cc.coptions=-O3 ^
config.bin.lib=shared ^
config.install.root=C:\build2
\
"
|
