Re: [boost] Best Practices Question: Building, Installing, and Using Boost in Corporate Environments
Aleksey Gurtovoy wrote:
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.
I think I see the merit to this option verses having only the boost_root committed to the repository and applying patches directly. With only the boost_root, it would quickly become impossible to discern what was patched previously and whether or not that patch needed to be carried forward to the next version/release of the library.
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.
In the rare case that you have to patch a .cpp file (as most libraries are only headers) do you mean that you are updating the original file to be just a shell that #includes the modified version? Or are you modifying the library's bjam to use the file from the patch directory? Or are you copying over the entire library whenever you have to patch?
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,
Yes - it certainly does! You completely covered my first two questions. If you don't mind me asking, do you also push into the repository the [few] libraries built with whatever compiler(s) you use? Or do you leave it up to the individual developer to build those libraries locally as needed? Thank you for your time, -Chris ____________________________________________________________________________________ Sponsored Link Online degrees - find the right program to advance your career. www.nextag.com
Christopher Woods writes:
Aleksey Gurtovoy wrote:
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.
I think I see the merit to this option verses having only the boost_root committed to the repository and applying patches directly. With only the boost_root, it would quickly become impossible to discern what was patched previously and whether or not that patch needed to be carried forward to the next version/release of the library.
Yep. Well, not literally impossible, but way too painful and error-prone.
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.
In the rare case that you have to patch a .cpp file (as most libraries are only headers) do you mean that you are updating the original file to be just a shell that #includes the modified version? Or are you modifying the library's bjam to use the file from the patch directory?
The latter, after copying it over to the patch directory.
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,
Yes - it certainly does! You completely covered my first two questions. If you don't mind me asking, do you also push into the repository the [few] libraries built with whatever compiler(s) you use?
On Windows, yes. On Mac OS X, they are built locally on each developer's machine as a part of a project's build process, but that's more a historical artifact than anything else. -- Aleksey Gurtovoy MetaCommunications Engineering
participants (2)
-
Aleksey Gurtovoy -
Christopher Woods