Mathias and OvermindDL1, thanks! Of course shipping part of Boost with my library might lead to substantial problems for users who use other parts of Boost not included with my code (and possibly other Boost versions than the one included in my code). They then have to be really careful which part of their overall application includes which header file from where, and which library(-versions) they link with. So I guess the best approach for me is to prevent only certain Boost versions from being used with my code (e.g. 1.41 is not usable in my context), and to work around more minor issues of other Boost versions. Alternatively I might make usage of local, bcp-extracted Boost libraries optional for the user. But that would require some massive hacking of my own CMakeLists.txt file. BTW, when playing with bcp, I noticed that some CMakeLists.txt files are generated or copied for most extracted Boost libraries, but that there is neither a top-level CMakeLists.txt, nor are some required cmake modules copied, that are otherwise shipped with Boost 1.40 . Thanks again and best Regards, Ruediger Mathias Gaunard wrote:
Ruediger Berlich wrote:
I am using a multitude of different Boost libraries in my code. Since that code is growing quickly, I am increasingly running into bugs which I (sometimes) consider to be on Boost's side.
Allowing only selected Boost versions which are known to run fine with my code would allow me to keep that code simpler and thus less error-prone. As my main platform is Linux, however, which usually comes with a given version of Boost (currently often 1.39), my users would be forced to compile Boost themselves, which will mean that they are less likely to start using my code.
If I generally allow all Boost versions above a given version, I have to work around known bugs in certain Boost versions, at the expense of code simplicity and thus stability. However, it will be easier for users to adopt my code.
Which strategy did you pick for your code ?
Ship the parts and versions of boost that you use.