liamv7 wrote:

Hi, I want to use boost at work. What's the best way to make this available to our developers? The options I see: 1. Put the include files and built libs/dlls in version control. I don't see much point to this and binaries take up a lot a space and it's annoying when upgrading. 2. Zip up the include files and dlls and have developers unzip in appropriate location. 3. Let developers access boost over network. To slow.

How do you guys manage this?

Hi Liam, I have seen the other replies, but I'll add my 2 cents. I have checked in the sources to our version control system (CVS). I have built the libraries once on each platform (Mac and Windows(), using bjam driven by a per-platform script. The script actually knows how to run bjam with the proper command line arguments, then it does whatever is necessary for the platform. For instance, on the Mac it moves the dylibs to a separate directory because otherwise you get link problems when you try to use static libraries. I check in the built libraries (with another script) and developers check out those binaries. The reason for this is that it lets me do internal releases of the libraries, and we always know how they were built. No one can have a local setup that can result in them making a different version of the library. We also do this for third party software tools. On the Mac, I also have scripts that will setup symlinks so that a developer can have a single checkout of the third party libraries and third party tools and share them among all of his build trees. It saves us from checking out the huge binaries into every development tree, which can be a little slow. This all took a while to figure out and setup, but it was well worth it because we have removed all build variability for all of our third party code. God knows we can create enough problems when writing our own software without throwing in per-developer build variability for a bunch of stuff that we didn't write. I had no problems with bjam at all, but YMMV. - Rush