aboutsummaryrefslogtreecommitdiffstatshomepage
diff options
context:
space:
mode:
-rw-r--r--_posts/2017-01-07-building-boost.md64
-rw-r--r--css/code-nowrap.css3
2 files changed, 42 insertions, 25 deletions
diff --git a/_posts/2017-01-07-building-boost.md b/_posts/2017-01-07-building-boost.md
index 193b786..5e71334 100644
--- a/_posts/2017-01-07-building-boost.md
+++ b/_posts/2017-01-07-building-boost.md
@@ -3,23 +3,35 @@ title: Building Boost on Windows
layout: post
excerpt: >
This post describes the process of building Boost on Windows using either
- Visual Studio or the combination of Cygwin & MinGW-w64.
+ Visual Studio or the combination of Cygwin + MinGW-w64.
+custom_css:
+ - code-nowrap.css
---
Below you can find the steps required to build Boost libraries on Windows.
These steps tightly fit my typical workflow, which is to use Boost libraries in
-CMake builds using either Visual Studio or the combination of Cygwin &
+CMake builds using either Visual Studio or the combination of Cygwin +
MinGW-w64.
I would expect, however, that the procedure for the latter toolset can easily
be adjusted for generic GCC distributions (including vanilla GCCs found in
popular Linux distributions).
-One of the features of this workflow is that I build throwaway, "run once on
-each VM, record the results, and scrap it" executables not more often than not,
-so I prefer to link everything statically, including for instance the C/C++
+One of the features of this workflow is that I build throwaway, "run
+everywhere, record the results, and scrap it" executables more often than not,
+so I prefer to link everything statically, including, for instance, C/C++
runtimes.
This is implemented by passing `runtime-link=static` to Boost's build utility
`b2`; change this to `runtime-link=dynamic` to link the runtime dynamically.
+Excerpts from shell sessions in this post feature a few different commands
+besides Boost's `b2` and `cmake`, like `cd` and `cat`.
+They are used to hint at my personal directory layout, display various
+auxiliary files, etc.
+Windows' `cd`, for example, simply prints current working directory; Cygwin's
+`pwd` serves the same purpose.
+`cat` is used to display files.
+Windows' command prompts are denoted with `>`s at beginning of each line;
+Cygwin's — with `$`s.
+
Visual Studio
-------------
@@ -50,7 +62,7 @@ D:\workspace\third-party\boost_1_61_0\msvc
### x64
The only important difference is that you have to pass `address-model=64` to
-`b2` (notice also the different "stage" directory).
+`b2` (notice also the different "staging" directory).
```
> cd
@@ -78,27 +90,29 @@ It is required to avoid file name clashes; unlike the Visual Studio "toolset"
whether the debug or the release version of a library was built) in file names.
Also, linking the runtime statically doesn't really make sense for MinGW, as it
-always links to msvcrt.dll, which is [simply Visual Studio 6.0 runtime].
+always links to msvcrt.dll, which is [simply the Visual Studio 6.0 runtime].
-[simply Visual Studio 6.0 runtime]: https://sourceforge.net/p/mingw-w64/wiki2/The%20case%20against%20msvcrt.dll/
+[simply the Visual Studio 6.0 runtime]: https://sourceforge.net/p/mingw-w64/wiki2/The%20case%20against%20msvcrt.dll/
In the examples below, only the debug versions of the libraries are built.
Build the release versions by executing the same command, and substituting
-`variant=release` and the proper "stage" directory path.
+`variant=release` instead of `variant=debug` and either
+`--stagedir=stage/x86/release` or `--stagedir=stage/x64/release`, depending
+on the target architecture.
### x86
```
-> cd
+$ pwd
/cygdrive/d/workspace/third-party/boost_1_61_0/mingw
-> ./bootstrap.sh
+$ ./bootstrap.sh
...
-> cat user-config-x86.jam
+$ cat user-config-x86.jam
using gcc : : i686-w64-mingw32-g++ ;
-> ./b2 toolset=gcc-mingw \
+$ ./b2 toolset=gcc-mingw \
target-os=windows \
link=static \
variant=debug \
@@ -114,24 +128,24 @@ using gcc : : i686-w64-mingw32-g++ ;
Notice the two major differences from the x86 example:
-* `b2 address-model=64 ...` (as in the example for Visual Studio),
-* the different user configuration file, pointing to `x86_64-w64-mingw32-g++`
+* the addition of `address-model=64` (as in the example for Visual Studio),
+* a different "user" configuration file, pointing to `x86_64-w64-mingw32-g++`
instead of `i686-w64-mingw32-g++`.
-Again, as in the example for Visual Studio, a different "stage" directory needs
-to be specified using the `--stagedir` parameter.
+Again, as in the example for Visual Studio, a different "staging" directory
+needs to be specified using the `--stagedir` parameter.
```
-> cd
+$ cd
/cygdrive/d/workspace/third-party/boost_1_61_0/mingw
-> ./bootstrap.sh
+$ ./bootstrap.sh
...
-> cat user-config-x64.jam
+$ cat user-config-x64.jam
using gcc : : x86_64-w64-mingw32-g++ ;
-> ./b2 toolset=gcc-mingw \
+$ ./b2 toolset=gcc-mingw \
address-model=64 \
target-os=windows \
link=static \
@@ -190,10 +204,10 @@ You may also want to adjust the paths.
#### x86
```
-> cd
+$ pwd
/cygdrive/d/workspace/build/test_project/mingw/x86/debug
-> cmake -G "Unix Makefiles" \
+$ cmake -G "Unix Makefiles" \
-D CMAKE_BUILD_TYPE=Debug \
-D CMAKE_C_COMPILER=i686-w64-mingw32-gcc \
-D CMAKE_CXX_COMPILER=i686-w64-mingw32-g++ \
@@ -206,10 +220,10 @@ You may also want to adjust the paths.
#### x64
```
-> cd
+$ pwd
/cygdrive/d/workspace/build/test_project/mingw/x64/debug
-> cmake -G "Unix Makefiles" \
+$ cmake -G "Unix Makefiles" \
-D CMAKE_BUILD_TYPE=Debug \
-D CMAKE_C_COMPILER=x86_64-w64-mingw32-gcc \
-D CMAKE_CXX_COMPILER=x86_64-w64-mingw32-g++ \
diff --git a/css/code-nowrap.css b/css/code-nowrap.css
new file mode 100644
index 0000000..ae47c0a
--- /dev/null
+++ b/css/code-nowrap.css
@@ -0,0 +1,3 @@
+code {
+ white-space: nowrap;
+}