Re: [boost] Best Practices Question: Building, Installing, and Using Boost in Corporate Environments

From: Aleksey Gurtovoy (agurtovoy_at_[hidden])
Date: 2006-11-21 14:42:56

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