Best Practices Question: Building, Installing, and Using Boost in Corporate Environments
Hello! I'm rather new to Boost and I'm thinking about starting to use the libraries in some of our software development but I'm a bit lost as to how best to bring Boost into our environment. I'm looking for any information, tips, best practices, etc... on how to properly incorporate Boost in the environment without overwhelming the other developers. Some information that may be of help in answering my questions: - We use MSVC 6.5 (as Boost defines it), MSVC 7.1, and MSVC 8.0 depending on the project. (There has never been any great push to port existing and legacy projects to the newer compilers I'm afraid.) - Depending on the project between 1 and 3 developers are involved. - I work solo on most of my projects, however some of the more common aspects of my code are reused in other related projects maintained by other developers. If I start using Boost in these areas then they will need it on their machines as well... Some starter questions: 1) Is it generally advisable to store a copy of Boost in a local corporate repository so that all developers are using the same revision of the libraries? Or do you just let/instruct users grab the latest official release from Boost.org? (If repository is recommended then do you push up just the source, source + compiled, or just the staged files?) 2) How do you deal with bugs found in or enhancements to the various libraries between major release versions? (I guess this depends greatly upon how you answer the previous question.) 3) Do you build Boost once for all toolsets and have developers copy the staged files to their local machines? Or is each developer responsible for building the libraries themselves? (I realize that a majority of the libraries are headers only but there is a fair number of libraries included that need to be compiled as well.) 4) How do Service Packs and Platform SDK updates affect the built libraries? Should the libraries be rebuilt any time these change? I'm sure there are a lot more questions - I just have to have somewhere to start on the path. Obviously, there are companies out there that are using Boost within their environment and so I'd love to gain insight from their experiences and approaches. Any other related information that could be provided would be most certainly welcomed as well. Thank you in advance, -Chris PS - Perhaps in the end this information will prove to be sufficient in nature to warrant creating a guide/FAQ for the new user(s) wishing to bring Boost into their corporate environs. Or maybe there is one already and I just missed it completely? __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Christopher Woods writes:
Some starter questions: 1) Is it generally advisable to store a copy of Boost in a local corporate repository so that all developers are using the same revision of the libraries?
I'd strongly recommend doing so.
Or do you just let/instruct users grab the latest official release from Boost.org? (If repository is recommended then do you push up just the source, source + compiled, or just the staged files?)
2) How do you deal with bugs found in or enhancements to the various libraries between major release versions? (I guess this depends greatly upon how you answer the previous question.)
I happened to recently commented on this one in another thread (http://article.gmane.org/gmane.comp.lib.boost.user/22781/), so I'll take a liberty of quoting myself: " IMHO this is a general issue: how do you manage a third-party library sources in presence of a need to make local patches to them, and keep these patches from getting overwritten accidentally? (Unless you always work with the HEAD / latest & greatest sources _and_ have a direct channel to the library maintainer, local patches are inevitable). Our answer to this question here at work is: 1) Always maintain a patch directory alongside with the root directory for the library sources, e.g.: boost_root/... boost_patches/... 2) Make the patch directory precede the original sources in the list of include paths. Do this and #1 at the very moment you import the library in your repository. 3) When a need for a patch occurs: a) Isomorphically copy the affected / add the new files into the patch directory, leaving the originals untouched, and patch the copies. If you need to delete the file, don't, but, depending on the use case, override it with an empty one or the one containing an #error directive / redirecting #include. b) Rebuild the library if needed (making sure to enforce #2). 4) When upgrading to a new version of the library, diff the patches against the new originals and delete/keep/adjust them depending on the results. " HTH, -- Aleksey Gurtovoy MetaCommunications Engineering
participants (2)
-
Aleksey Gurtovoy -
Christopher Woods