I'm trying setup a subset of boost and get it properly compiled using bjam, however I'm not getting the result I'm looking for. I'm working on windows using boost 1.37.0.
Let's say I want the libraries smart_ptr and filesystem built/installed. I intentionally chose a header only library and one library needing to compile a library. I want them to be built into a directory structure similar to the one I would get if I built a complete boost installation with bjam (i.e not specifying any --with-libraryX) but of course without all the libraries I'm not interested in.
My first approach was to use the --with-filesystem --with-smart_ptr in bjam, however it seemed like it didn't recognize smart_ptr (I tried smartptr and smart-ptr without success). I guess this is because it's a header only library.
When I removed it and only had --with-filesystem it seemed to copy ALL libraries header files to the install path and only build the libraries for filesystem. The library building behavior was the one I hoped for, but I got tons of header files for libraries I'm not interested in installed in my boost directory.
My second approach was to use bcp to copy the relevant projects. This did work out in the sense that I only got the projects I cared about (and their dependencies). However they didn't provide any make files for building the libraries that was copied. This means I would need to setup projects files for all the libraries that are not header only and manually build them.
So my question is basically, is there a way of selectively building boost that only copies the headers for the libraries I'm interested in and only building library files for the non header only libraries I'm interested in (and the boost libraries they are dependent on course)?
There are probably tons of manual/scripting based solutions for this, but if I could get something running only using bjam would be way more useful for me since adding new libraries or upgrading to a new boost version would be very simple.
EDIT:
Added the complete command line for the first approach:
bjam install --prefix=c:\temp\boostsmall
--build-dir=C:\temp\boostsmalltemp --layout=system
--with-filesystem variant=debug link=static threading=multi
runtime-link=static
Changed scoped_ptr to smart_ptr
Solved it.
The bcp solution had make files for the projects, however I needed to copy the tools directory and the root of the boost directory to the place I copied all my libs to get things up running.
Great question! This is an issue I have recently managed to figure out, I think.
I already had the full Boost libraries installed, including the ones requiring separate compilation.
I managed to create a subset of the Boost libraries (regex) for a particular application I was working on using the following steps:
First ensure the bcp executable is installed in the first place. In your Boost root folder, navigate to the tools/bcp folder and run the bjam.exe in here. For me this created the bcp executable in [Boost path]\bin.v2\tools\bcp\msvc-10.0\release\link-static directory:
Then create the folder where you would like the Boost subset to reside. This might already be a folder for a Visual Studio project you are working on.
Run the bcp exectubale you created, making sure to include the libraries you wish to include, as well as the location of the boost root directory and the destination folder. Observe how the required Boost components (eg for regex) have been included in your destination folder.
bcp.exe regex --boost="C:\Program Files\boost_1_55_0\boost_1_55_0" C:\Projects\RegexProject\BoostLite
In your Visual Studio project set the Additional Include Directories and Libraries to point to the 'Boost lite' folder that was created.
One final thing - which I think is described previously - I needed to go to my regular Boost folder setup and copy the required stage/lib folder containing all the lib files needed for the subset version and copy them here, just a few regex-related lib files in my case.
I found that this worked for me. Any feedback from other persons experiences would be appreciated.
A blog posting describing the same thing can be found here.
Related
While trying to build the thrift c++ library, I came across the following error after specifying the --with-boost option.
If you have a staged boost library (still not installed) please
specify $BOOST_ROOT in your environment and do not give a PATH to
--with-boost option.
I looked through the boost documentation (which is I am not overly familiar with), but I did not find a good definition for the term staged boost library. I see the parenthetical (still not installed), but there are many states that are a library can be in that fall under the category of not installed.
When I first download boost, I run ./bootstrap and ./b2 to compile it.
Is it staged at this point? Or do I have to do something else to make it staged?
You can call
b2 --help
to see options of Boost.Build, and there you can find
install Install headers and compiled library files to the
======= configured locations (below).
...
stage Build and install only compiled library files to the
===== stage directory.
The declaration of stage or install specifies whether the Boost Libraries are installed in a subfolder named stage or system-wide. The meaning of system-wide depends on the operating system. In Windows, the target directory is c:\boost, in Linux it is /usr/local. The target directory can also be explicitly specified using the -–prefix option. Also see this answer, I guess it will be helpful.
For more informations see Getting Started Guide for Windows or Linux.
When you run .\b2 to compile Boost, it create a folder called stage and output of the compilation is put inside %BOOST_ROOT%\stage\lib folder. Now you can copy this lib folder somewhere and add that in to linker's path. However some projects might expect binaries to be available at stage\lib. So "staged" here means if you have libraries compiled and present in stage\lib folder. The .b2 command takes several different parameters to compile different kids of binaries, for example, below compiles binaries that are linked to shared runtime and targeting x64 architecture:
b2 variant=debug,release link=shared runtime-link=shared address-model=64
Each variant of lib file name has tags so they don't overwrite each other, for example, libboost_date_time-vc140-mt-gd-1_62.lib.
I've downloaded, extracted, and compiled the Boost libraries (including the separately compiled libraries). I've used their install procedure a couple times now but I can't seem to get it to do exactly what I want. Right now, when I install Boost after compiling it goes to
C:\Boost
This is fine. The compiled libs go to
C:\Boost\lib
which is also fine. The problem I have is with the installation of the precompiled headers. They got put at
C:\Boost\include\boost-1_54\boost
Is there a way to use the Boost build system and install tools to set the precompiled headers to be installed to just
C:\Boost\include
and not have the Boost version number be a part of that folder hierarchy?
I don't plan on using multiple versions of Boost at the same time so I don't have a use for actually having that version number. I realize I could move them manually after the install is complete, but I wanted to see first if I've overlooked or misunderstood something about Boost's build system.
--layout=system removes the versioned subdirectory from the include path (as #IgorR. pointed out).
"Removing that second boost in the path" is a bad idea. In a respectable OS (cough...), the include files for various libraries are supposed to co-exist in one common include directory, hence the boost subdirectory to avoid clashes. Boost headers are therefore habitually referred to as e.g. #include <boost/any.hpp>, i.e. including that boost/ subdirectory.
This is done both by third-party software using Boost, and by Boost itself. If you remove the second boost from the path, you would end up with C:\Boost\include\any.hpp, and any Boost-using software won't compile as not even Boost could find its own includes.
I'm working on multiple projects at the same time (some libraries, and some games that depend on them). They're all on GitHub, in separate repos.
For convenience, I pull every repo in a "workspace folder", like this:
/home/myWorkspace/Library1/
/home/myWorkspace/Library2/
/home/myWorkspace/Library3/
/home/myWorkspace/App1/
/home/myWorkspace/App2/
I have FindLibrary1, FindLibrary2 and FindLibrary3 .cmake files, which, in order, look for the library in ../ (which corresponds to the "myWorkspace" folder), then /usr/lib/.
While on Windows CMake finds the libraries in myWorkspace/, on Linux, no matter what, installed libraries are always found first.
Since I'd like to work in myWorkspace/ folder, then installing the libraries after I'm done, I'd prefer CMake to find and link everything within the myWorkspace/ folder.
I'd also like CMake to search for the libraries in /usr/lib/ and /usr/local/lib/ if there is no myWorkspace/ folder, but if myWorkspace/ exists, it should have the priority.
Examples of CMake files I'm using:
SSVUtils: library with no dependancies
SSVUtils CMakeLists: https://github.com/SuperV1234/SSVUtils/blob/master/CMakeLists.txt
FindSSVUtils.cmake: https://github.com/SuperV1234/SSVUtils/blob/master/cmake/modules/FindSSVUtils.cmake
SSVUtilsJson: library that depends on SSVUtils and SSVJsonCpp
SSVUtilsJson CMakeLists: https://github.com/SuperV1234/SSVUtilsJson/blob/master/CMakeLists.txt
FindSSVUtilsJson.cmake: https://github.com/SuperV1234/SSVUtilsJson/blob/master/cmake/modules/FindSSVUtilsJson.cmake
Any ideas how I can prioritize the myWorkspace/ folder while still having the possibility to find libs in file system paths?
By default, find_path (or find_library, etc.) first checks for files in the system standard locations, before searching in the values provided in PATH. That's why "installed" libraries are always found first on Linux (but not on Windows, that doesn't have standard locations for installed libraries).
You can disable that behavior by using the NO_CMAKE_SYSTEM_PATH option: it will skip detection of files in standard locations.
Now... if you still want to use the installed libraries as a fallback when local versions are not found, you can do it in a two step process:
find_path(... NO_CMAKE_SYSTEM_PATH)
if (nothing_found)
find_path(...)
endif()
I'm reasonably new to C++, and I was going to mess around with threading for my Tamagochi game, however it seems that everything says I should get Boost for that.
So my question is, how on earth do I install it?
I've found ways of using it by doing the whole "Add the path in the properties" thing. And that works, however I'm guessing that if I use that way, I wont be able to compile and release it afterwards?
I also tried using BlueGo from vertexwahn.de.
but I have no idea what it actually does. I get the whole "It compiles the libraries for you" thing but, how do I use them then?
Should they work from within VS2012 without further tweaking, or do I still need to add in the path's in properties?
I just want to use the threading from Boost, and then build the project and send to a friend.
I was going to mess around with threading...
If my reading of MSDN is correct, Visual Studio 2012 appears to support the new threading features of C++ 11. With this in mind, you don't need to install Boost. You can just use the standard <thread> header instead.
Some boost modules have to be built.
For Windows, you have to use bjam.exe to build your libraries.
And bootstrap.bat will build you bjam.exe
From your unzipped boost directory :
bootstrap.bat
bjam.exe release debug toolset=msvc address-model=32 --build-type=complete
bjam.exe release debug toolset=msvc address-model=64 --build-type=complete
And check your stage/lib for *.lib, *.dll
(You may have to clean your stage/lib directory between two bjam commands)
Then, add include directory and library directory to your VS project.
Needed libraries will be automatically linked (you do not have to tell VS to use boost thread for example), boost use pragma to find out what is needed. It doesn't work for Linux though.
As previously stated, VS2012 already handle threads, but boost is much more than that and I strongly recommand using it for whatever you want to code.
With asio from boost, you can even make thread pool : see recipe
download boost
compile boost (go to the boost directory, call
bootstrap and after this is finished call b2)
decide which part of boost to use
add the main boost directory to your include path and the lib (with default it is in stage - just search for the lib files) directory to your linker path
make sure that you link boost thread dynamically (there may be problems if you link statically)
program
According to this answer, the intended way to include non-header-only parts of Boost into a Visual Studio 2010 project require the use of bjam to build the correct libraries.
What is unclear to me is whether this is a one-time-only thing, where I just check in the lib files produced by bjam, or whether anyone who wants to build my project will from now on require not only Visual Studio but also bjam.
The project only targets Windows 32-bits, because it builds a plugin for a program that's only available in this configuration, and only needs to support the statically-linked multi-threaded CRT.
(For the record, if I just include the relevant .cpp files into the build, the compile stage succeeds, but at link stage I get a missing library error, which is apparently caused by the "auto-link" feature. Perhaps I should just disable auto-linking, if it's possible?)
You don't need bjam. Like yasouser answered, you can download the installer from boost pro, the downsides being that
you need to register though that's quick and easy
it's usually/sometimes a release or two behind the latest boost release.
What is unclear to me is whether this is a one-time-only thing, where I just check in the lib files produced by bjam, or whether anyone who wants to build my project will from now on require not only Visual Studio but also bjam.
It is a one time thing per machine. Once you have the boost binaries you don't need bjam anymore. The nice thing about the installer is that you can install some selected versions of the boost libraries + the headers (You can select VS version, single-threaded, static/dynamic, etc. on a per library basis e.g. thread, system, etc.) and then at a later point you can just run the installer again and add other binaries.
So if you're auto-linking and are missing a specific lib, just run the installer again.
FYI, you can disable boost's autolinking option by defining BOOST_ALL_NO_LIB and then manually linking in the lib versions you want.
Some of the boost libraries require you to build them as static or shared libraries and link them in your project. Either you can download the source and build it for yourself using bjam or you can install the pre-built binaries from here.
Yes this is a one time install (if you are installing from pre-built binaries or built by yourself). And those building your project will also need to do the boost install once for them to be able to build your project.
if I just include the relevant .cpp
files into the build
Direct including cpp files has many drawbacks. The only reason of borrowing .cpp files I can imagine is to allow build the project on other PCs without installing boost there. But I think it can be solved by distributing particular boost .lib files as well.