On 5/29/15 11:12 AM, Stefan Seefeld wrote:
On 29/05/15 02:04 PM, Robert Ramey wrote:
On 5/29/15 9:31 AM, Stefan Seefeld wrote:
As I mentioned, all I want is being able to build and release Boost.Python independently. No changes to the (C++) code are involved to achieve this.
How would you plan to do this? A fork of Boost.Python, or unilaterally make changes in the current version of Boost.Python?
I'm already experimenting on a fork (https://github.com/stefanseefeld/boost.python/tree/standalone). I'm proposing to push those changes (once stable) to the official Boost.Python. (Not sure what you mean by "unilaterally". The very reason I'm bringing
OK - I've looked at the fork and see what you want to do and I still have a few questions; a) I perused the python library source code and it includes only couple of boost header files. So it's not really dependent on the rest of boost at all. Not a good or bad thing - just an observation. b) I see that your proposal just involves changes in the jamfiles eliminating dependencies on some other jamfiles. Actually I didn't even realize that a libraries jamfiles actually depended upon the root. Now that I realize this I see the logic of it. If you can do this I don't see any downside to it. It doesn't conflict with anything else.
All I'm suggesting is to build and release Boost.Python stand-alone, against an external Boost installation.
c) It seems to me that you wouldn't even need boost installed to do this. Again not a good or bad thing.
For avoidance of doubt: my intent is not to remove Boost.Python out of the Boost organization.
d) regardless of your intent, that decision to include or exclude boost python in a "release" would be a separate question. I don't think you could prevent any boost library from being included in the "boost release"
Does this mean the ability to "release (distribute ?) Boost.Python without waiting for a boost release?
Yes.
Actually, this what we want to be able to do for all boost libraries. See the related initiative proposed in the steering committee mailing list. This has been proposed as a long term goal. But it seems (as usual) that current events out flank long term plans. While you're at it, Why not include CMake files so that the build/test of Boost python be totally decoupled from from the boost build system. I did this for the boost serialization library so in your world this would look like the ability to deliver the latest master version of the boost serialization library independently of the next release. In fact, that is exactly what I recommend to users who have detected errors in a couple of corner cases of the library which have since been fixed. Basically, you should think bigger. Robert Ramey