While Nate's answer is pretty good already, I'm going to expand on it more specifically for Visual Studio 2010 as requested, and include information on compiling in the various optional components which requires external libraries.
If you are using headers only libraries, then all you need to do is to unarchive the boost download and set up the environment variables. The instruction below set the environment variables for Visual Studio only, and not across the system as a whole. Note you only have to do it once.
- Unarchive the latest version of boost (1.47.0 as of writing) into a directory of your choice (e.g.
C:\boost_1_47_0).
- Create a new empty project in Visual Studio.
- Open the Property Manager and expand one of the configuration for the platform of your choice.
- Select & right click
Microsoft.Cpp.<Platform>.user, and select Properties to open the Property Page for edit.
- Select
VC++ Directories on the left.
- Edit the
Include Directories section to include the path to your boost source files.
- Repeat steps 3 - 6 for different platform of your choice if needed.
If you want to use the part of boost that require building, but none of the features that requires external dependencies, then building it is fairly simple.
- Unarchive the latest version of boost (1.47.0 as of writing) into a directory of your choice (e.g.
C:\boost_1_47_0).
- Start the Visual Studio Command Prompt for the platform of your choice and navigate to where boost is.
- Run:
bootstrap.bat to build b2.exe (previously named bjam).
Run b2:
- Win32:
b2 --toolset=msvc-10.0 --build-type=complete stage ;
- x64:
b2 --toolset=msvc-10.0 --build-type=complete architecture=x86 address-model=64 stage
Go for a walk / watch a movie or 2 / ....
- Go through steps 2 - 6 from the set of instruction above to set the environment variables.
- Edit the
Library Directories section to include the path to your boost libraries output. (The default for the example and instructions above would be C:\boost_1_47_0\stage\lib. Rename and move the directory first if you want to have x86 & x64 side by side (such as to <BOOST_PATH>\lib\x86 & <BOOST_PATH>\lib\x64).
- Repeat steps 2 - 6 for different platform of your choice if needed.
If you want the optional components, then you have more work to do. These are:
- Boost.IOStreams Bzip2 filters
- Boost.IOStreams Zlib filters
- Boost.MPI
- Boost.Python
- Boost.Regex ICU support
Boost.IOStreams Bzip2 filters:
- Unarchive the latest version of bzip2 library (1.0.6 as of writing) source files into a directory of your choice (e.g.
C:\bzip2-1.0.6).
- Follow the second set of instructions above to build boost, but add in the option
-sBZIP2_SOURCE="C:\bzip2-1.0.6" when running b2 in step 5.
Boost.IOStreams Zlib filters
- Unarchive the latest version of zlib library (1.2.5 as of writing) source files into a directory of your choice (e.g.
C:\zlib-1.2.5).
- Follow the second set of instructions above to build boost, but add in the option
-sZLIB_SOURCE="C:\zlib-1.2.5" when running b2 in step 5.
Boost.MPI
- Install a MPI distribution such as Microsoft Compute Cluster Pack.
- Follow steps 1 - 3 from the second set of instructions above to build boost.
- Edit the file
project-config.jam in the directory <BOOST_PATH> that resulted from running bootstrap. Add in a line that read using mpi ; (note the space before the ';').
- Follow the rest of the steps from the second set of instructions above to build boost. If auto-detection of the MPI installation fail, then you'll need to look for and modify the appropriate build file to look for MPI in the right place.
Boost.Python
- Install a Python distribution such as ActiveState's ActivePython. Make sure the Python installation is in your PATH.
To completely built the 32-bits version of the library requires 32-bits Python, and similarly for the 64-bits version. If you have multiple versions installed for such reason, you'll need to tell b2 where to find specific version and when to use which one. One way to do that would be to edit the file project-config.jam in the directory <BOOST_PATH> that resulted from running bootstrap. Add in the following two lines adjusting as appropriate for your Python installation paths & versions (note the space before the ';').
using python : 2.6 : C:\\Python\\Python26\\python ;
using python : 2.6 : C:\\Python\\Python26-x64\\python : : : <address-model>64 ;
Do note that such explicit Python specification currently cause MPI build to fail. So you'll need to do some separate building with and without specification to build everything if you're building MPI as well.
Follow the second set of instructions above to build boost.
Boost.Regex ICU support
- Unarchive the latest version of ICU4C library (4.8 as of writing) source file into a directory of your choice (e.g.
C:\icu4c-4_8).
- Open the Visual Studio Solution in
<ICU_PATH>\source\allinone.
- Build All for both debug & release configuration for the platform of your choice. There can be a problem building recent releases of ICU4C with Visual Studio 2010 when the output for both debug & release build are in the same directory (which is the default behaviour). A possible workaround is to do a Build All (of debug build say) and then do a Rebuild all in the 2nd configuration (e.g. release build).
- If building for x64, you'll need to be running x64 OS as there's post build steps that involves running some of the 64-bits application that it's building.
- Optionally remove the source directory when you're done.
- Follow the second set of instructions above to build boost, but add in the option
-sICU_PATH="C:\icu4c-4_8" when running b2 in step 5.
All C++ compilers have one serious performance problem to deal with. Compiling C++ code is a long, slow process.
Compiling headers included on top of C++ files is a very long, slow process. Compiling the huge header structures that form part of Windows API and other large API libraries is a very, very long, slow process. To have to do it over, and over, and over for every single Cpp source file is a death knell.
This is not unique to Windows but an old problem faced by all compilers that have to compile against a large API like Windows.
The Microsoft compiler can ameliorate this problem with a simple trick called precompiled headers. The trick is pretty slick: although every CPP file can potentially and legally give a sligthly different meaning to the chain of header files included on top of each Cpp file (by things like having different macros #define'd in advance of the includes, or by including the headers in different order), that is most often not the case. Most of the time, we have dozens or hundreds of included files, but they all are intended to have the same meaning for all the Cpp files being compiled in your application.
The compiler can make huge time savings if it doesn't have to start to compile every Cpp file plus its dozens of includes literally from scratch every time.
The trick consists of designating a special header file as the starting point of all compilation chains, the so called 'precompiled header' file, which is commonly a file named stdafx.h simply for historical reasons.
Simply list all your big huge headers for your APIs in your stdafx.h file, in the appropriate order, and then start each of your CPP files at the very top with an #include "stdafx.h", before any meaningful content (just about the only thing allowed before is comments).
Under those conditions, instead of starting from scratch, the compiler starts compiling from the already saved results of compiling everything in stdafx.h.
I don't believe that this trick is unique to Microsoft compilers, nor do I think it was an original development.
For Microsoft compilers, the setting that controls the use of precompiled headers is controlled by a command line argument to the compiler: /Yu "stdafx.h". As you can imagine, the use of the stdafx.h file name is simply a convention; you can change the name if you so wish.
In Visual Studio 2010, this setting is controlled from the GUI via Right-clicking on a CPP Project, selecting 'Properties' and navigating to "Configuration Properties\C/C++\Precompiled Headers". For other versions of Visual Studio, the location in the GUI will be different.
Note that if you disable precompiled headers (or run your project through a tool that doesn't support them), it doesn't make your program illegal; it simply means that your tool will compile everything from scratch every time.
If you are creating a library with no Windows dependencies, you can easily comment out or remove #includes from the stdafx.h file. There is no need to remove the file per se, but clearly you may do so as well, by disabling the precompile header setting above.
Best Answer
Under ReSharper > Options > Tools > External Sources, select Default Visual Studio navigation (or "Navigation to Sources" for a wider set of navigation options incl. decompilation and fetching stuff from symbol servers)