On 29/05/15 11:19 PM, David Sankel wrote:
The big thing I would need to see in order to support your proposal is an explanation of how it would handle dependency issues.
That's a good question. Ideally, Boost would be componentized to the point where it would be easy to enumerate Boost.Python's dependencies not on header files but on projects. But that's somewhat tangential to the actual issues, so let's for now assume a simple split between Boost.Python and the rest (or the subset of Boost that Boost.Python requires).
Which version of the rest of Boost would Boost.Python require?
Ideally it wouldn't matter. In practice, there is of course the danger that some change would be introduced to Boost (the remainder) that breaks Boost.Python. This is a problem, well beyond Boost.Python, as this means that such a change may affect other Boost users, too. Unfortunately, so far there is absolutely no guarantee that any Boost release N+1 is backward compatible with release N. I believe that it is more than time for Boost to strive for backward compatibility, and to make it very clear whenever any API-level incompatibilities are introduced, so users can adjust. With that knowledge, Boost.Python can address such changes using the usual logic (configure / compile-time checks with conditional code). As I mentioned again and again, such a process is extremely common in the Free Software world when projects rely on third-party software (mostly libraries), and need to adjust to API changes.
Is there any chance that a Boost upgrade would break the current release of Boost.Python?
Sure, but I think it's Boost's (the remainder's) responsibility to document whenever such a change is introduced, to allow Boost.Python developer's (as well as any Boost users who may encounter such a change, for that matter !) to adjust.
If other libraries follow suit, how would the dependency issues effect them? As a user of Boost, what extra steps or effort would be needed to deal with the new dependency problem? (One benefit of the current lock-step release model is that we get an implicit guarantee that all the boost libraries in a particular release are compatible with each other).
Yes, and I agree that is a big convenience. Whenever a project 'A' depends on libraries 'B' and 'C' (say), it needs to run tests to determine that a particular range of versions of 'B' and 'C' work with 'A' (whether that requires any conditional logic in 'A' or not), and document that properly (as well as encode that into the build system to flag attempts to build against incompatible versions of 'B' and 'C'). Again, the real issue here is quite independent of my attempt to decouple Boost.Python from the rest of Boost: It's that as far as Boost is concerned, there has never been any explicit or implied guarantee that subsequent Boost releases are API compatible (or even ABI compatible !). I think it's time to rethink that.
Thanks in advance for your thoughts.
Thanks for your encouraging feedback ! Stefan -- ...ich hab' noch einen Koffer in Berlin...