aboutsummaryrefslogtreecommitdiff
path: root/BOOTSTRAP-UNIX.cli
diff options
context:
space:
mode:
Diffstat (limited to 'BOOTSTRAP-UNIX.cli')
-rw-r--r--BOOTSTRAP-UNIX.cli84
1 files changed, 19 insertions, 65 deletions
diff --git a/BOOTSTRAP-UNIX.cli b/BOOTSTRAP-UNIX.cli
index aee6fd9..26d5513 100644
--- a/BOOTSTRAP-UNIX.cli
+++ b/BOOTSTRAP-UNIX.cli
@@ -177,28 +177,6 @@ $ build2/build2/b-boot configure \
$ build2/build2/b-boot install: build2/ bpkg/
\
-\N|The above command will build all the dependencies of \c{build2} and
-\c{bpkg} from sources bundled with \c{build2-toolchain}. If instead you would
-like to use system-installed versions for some of them, then you can specify
-empty \c{config.import.*} values to disable the use of the bundled versions.
-For example, to use the system-installed SQLite:
-
-\
-$ build2/build2/b-boot configure \
- ... \
- config.import.libsqlite3=
-\
-
-If performing an installation with the \c{build.sh} script, then to use the
-system-installed dependencies pass the \c{--system} option, specifying such
-dependencies as a comma-separated list. For example:
-
-\
-$ ./build.sh --system libsqlite3,libpkg-config g++
-\
-
-|
-
The strange-looking \c{config.install.data_root=root/stage} means install
data files (as opposed to executable files) into the \c{stage/} subdirectory
of wherever \c{config.install.root} points to (so in our case it will be
@@ -244,18 +222,17 @@ a local installation and skip the rest of the steps.
To perform a local installation you will need to change the \c{configure} and
\c{install} command lines above along these lines (see also notes on the
-following step about only building shared libraries, private installation
-subdirectory, toolchain executables prefix/suffix, etc):
-
-\
-$ build2/build2/b-boot configure \
- config.config.hermetic=true \
- config.cxx=g++ \
- config.cc.coptions=-O3 \
- config.bin.lib=shared \
- config.bin.rpath=/usr/local/lib/build2 \
- config.install.root=/usr/local \
- config.install.private=build2 \
+following step about only building shared libraries, toolchain executables
+prefix/suffix, etc):
+
+\
+$ build2/build2/b-boot configure \
+ config.config.hermetic=true \
+ 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
$ build2/build2/b-boot install: build2/ bpkg/ bdep/
@@ -297,30 +274,20 @@ $ cd .. # Back to build2-build/
$ mkdir build2-toolchain-X.Y
$ cd build2-toolchain-X.Y
-$ bpkg-stage create \
- cc \
- config.config.hermetic=true \
- config.cxx=g++ \
- config.cc.coptions=-O3 \
- config.bin.lib=shared \
- config.bin.rpath=/usr/local/lib/build2 \
- config.install.root=/usr/local \
- config.install.private=build2 \
+$ bpkg-stage create \
+ cc \
+ config.config.hermetic=true \
+ 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
\
\N|The above configuration will only build shared libraries. If you would like
to build both shared and static, remove \c{config.bin.lib=shared}.|
-\N|The above configuration will install shared libraries that \c{build2}
-depends on into a private subdirectory. This is primarily useful when
-installing into a shared location, such as \c{/usr/local/}. By hiding the
-libraries in the private subdirectory we make sure that they will not
-interfere with anything that is already installed into such a shared location
-and that any further such installations won't interfere with \c{build2}. If,
-however, you are installing into a private location, such as \c{/opt/build2/},
-then you can remove \c{config.install.private=build2}.|
-
\N|To add a custom prefix/suffix to the toolchain executables names, add
\c{config.bin.exe.prefix=...} and/or \c{config.bin.exe.suffix=...}.|
@@ -340,19 +307,6 @@ $ bpkg-stage build --for install build2 bpkg bdep
$ bpkg-stage install --all
\
-\N|The above command will build all the dependencies of \c{build2}, \c{bpkg},
-and \c{bdep} from source packages. If instead you would like to use
-system-installed versions for some of them, then you can list them with the
-\c{sys} scheme to make \c{bpkg-stage} treat them as available from the system
-rather than building them from source. For example, to use the
-system-installed SQLite:
-
-\
-$ bpkg-stage build --for install build2 bpkg bdep ?sys:libsqlite3
-\
-
-|
-
\N|By default \c{bpkg} will build the latest available version of each
package. You can, however, specify the desired versions explicitly, for
example: