views:

1006

answers:

9

I want to get started using Boost. I'm programming a C++ program in Visual Studio (obviously on a Windows machine).

Boost's Getting Started Guide says:

The easiest way to get a copy of Boost is to use an installer. The Boost website version of this Getting Started guide will have undated information on installers as they become available, or see Boost downloads or the installer provided by BoostPro Computing. We especially recommend using an installer if you use Microsoft Visual Studio, because the installer can download and install precompiled library binaries, saving you the trouble of building them yourself.

I'm a little unsure if I want to follow this advice, or just download and build everything myself. Potential problems that I see with an installer are:

  1. Things are no longer self-contained (i.e. every team member has to install Boost, then configure Visual Studio to recognize it).
  2. I can't keep Boost under source control (I would ideally like it to be soure files in my source control like everything else). (Edit: Judging by the comments, it looks like boost is kinda large (as in 5 GB!), so obviously I'd need to keep only parts of it under source control).

So my question is, am I just being paranoid and should go the installer route, or am I correct and should build it myself? If anyone has any experience working with Boost and Visual Studio, I'd appreciate if they could share their views on this (and if it should be to build it myself, any tips would also be appreciated, for example should I only copy every file that I actually use? etc.).

Note:

A few similar questions on StackOverflow, but which didn't ask this explicitly, make me think that I shouldn't use the installer, which is why I'm asking it explicitly here. For reference, these are the questions:

  1. Boost linking, Visual Studio & version control
  2. Including Relevant Boost Libraries with C++ Source (Using Visual Studio)
A: 

Several points NOT to keep it under source control:

  1. Boost is huge.
  2. Compilation is non-trivial (esp. for several configurations)
  3. Compilation is long (you don't want every developer to do it)

I personally would not bother building it myself - on Linux, for instance I always use the distribution provided package.

EFraim
3) isn't really an issue IMHO as it is a one-time operation. Heck, you could even do it once and pass the compiled code around as a ZIP.
DevSolar
@DevSolar - if you are doing it, than there is no reason not to use the installer.
EFraim
A: 

I'd use the installer, unless you need to customize the build flags. It's much easier, and building boost (at least the last time I did it) wasn't the clearest process. There's nothing stopping you from downloading the source that matches the version of boost that the installer gives you, and putting that in version control. This is the approach I've used in the past for other libraries (nss, iplanet sdk) and it's worked well.

Jeff Paquette
+8  A: 

A good way to make sure everyone has everything configured properly is to use svn externals. You can create something like /trunk/boost1.35 and then you can point to that with an svn external.

That way as new versions of boost come out, you can just repoint your svn external to /trunk/boost1.40

In your repository, your svn external points to that svn folder within your repository. Example /depends/boost

We personally keep the boost header files under source control as described but keep the libs as a zip that we require everyone to download. We have an environment variable something like the following BOOST_LIB and we point that to the current boost library directory.

Brian R. Bondy
we do this at my workplace also
Matt Joiner
+2  A: 

I have built Boost under Windows. Its "bjam" installation tool auto-detects MSVC and uses it for compiling; I wouldn't have any reservations against building yourself. It's only marginally more difficult than "./configure && make && make install", really.

Building yourself could even be necessary, because the Boost libs available online do not include ICU (Unicode) support, e.g. for the boost_regex lib.

DevSolar
Interesting note about Unicode support, that's definitely something I will need in my project in the future.
Edan Maor
+1  A: 
  1. Things are no longer self-contained (i.e. every team member has to install Boost, then configure Visual Studio to recognize it).
  2. I can't keep Boost under source control (I would ideally like it to be soure files in my source control like everything else).

Before you put Boost under source control, keep in mind that the compiled libraries take up several gigabytes. (my Boost folder is around 5GB) It might be worth just letting everyone install Boost for themselves.

Apart from this, the installer should work fine, but compiling it yourself is really trivial as well.

Boost installs into version-specific folders by default (both if you compile it yourself and if you use the installer), so it's easy enough to have multiple versions installed side by side. So if your team upgrades Boost to a new version, you could simply change the include path in the .sln or .vsprops files to make the compiler search for the new version -- if a coworker hasn't installed the right version, he just won't be able to build (which might be preferable to silently building with an old version)

jalf
The real problem with everyone installing it for themselves, is that it makes upgrading to a new version very difficult. You have to have everyone jump at the same time, across all the branches of code.
teeks99
True. But again, each individual developer is notified because they get build errors if they try to build a branch that relies on a version of Boost they don't have. I'm not saying this is a perfect solution, just that putting 5GB of compiled files in source control doesn't seem ideal either. Perhaps it (all used versions of it) should be installed on a shared network folder that everyone can access, allowing for centrally installing new versions without bothering individual developers.
jalf
+3  A: 
ravenspoint
Thanks for the reply, could you please explain why I need to copy the libraries from libs to lib? You say not to confuse them, and actually the tutorial on the Boost website itself says to build exactly like you said, but then point Visual Studio at C:\Program Files\boost\boost_1_40_1\lib, no s, even though it doesn't exist. It doesn't mention anything about having to copy to lib. Is there something I'm missing? Why the discrepancy?
Edan Maor
I do not know the why. I do know that when I followed the procedure I described, it was neccessary - the library binaries were not in /lib, but sprinkled around in /bin.v2. Perhaps it was a bug, now fixed? What happens when you try it? Do the librsaries end up in the correct places without you having to move them?
ravenspoint
The might be various inconveniences in prior versions, but in 1.40, running "bjam" without any options, puts the libraries to 'stage\lib'. You don't need to copy anything manually.
Vladimir Prus
I was building 1.40 I wonder - am I the only person for whom this did not work - i.e. the libraries had to be copied manually?
ravenspoint
@Vladimir Prus: Thanks for the heads up, I didn't realize that. I might have missed it, but I think it wasn't documented in the Boost documentation...
Edan Maor
+1  A: 

One other thing to consider is whether you need all or part of boost. What we do here is put the source in version control and create a single wrapper project for the libraries that we actually want to use. The individual libraries are written cleanly enough to make it a matter of just dropping all the cpp files into a new visual studio project. You might need to set up the top level configuration header (I think I set this as a forced include) and the whole thing built very easily. Add this project as a dependency in your solution and it means you can keep all the binaries out of the SCM and also ensure that everyone is always up-to-date.

Much of boost is headers-only anyway so you may find that there's only a handful of libraries that you'd want to build. This approach makes it easier for you to match your VS project settings too.

the_mandrill
A: 

I would recommend to run bootstrap.bat first - it will build bjam.exe and then

bjam --stagedir="c:\Program Files\Boost" --build-type=complete --toolset=msvc-9.0 --with-regex --with-date_time --with-thread --with-signals --with-system --with-filesystem --with-program_options stage

bjam --stagedir="c:\Program Files\Boost" --build-type=complete --toolset=msvc-10.0 --with-regex --with-date_time --with-thread --with-signals --with-system --with-filesystem --with-program_options stage

..

You just need to specify the correct toolset. It will put all binaries to the ..\lib folder.

Sergei
A: 

We actually create our own installer, with just the parts of Boost that we use in our jobs, and give that out to the IT folks to install on developer machines. We also keep that copy of boost in revision control, so we can track dependencies between it and the rest of our system properly, and build it ourselves.

I suppose work-wise this is the worst of both worlds. But it does give us the maximum control.

T.E.D.