Is Boost-CMake Dead or Alive?
http://ryppl.org/news/ So the boost-svn tracking is now hosted at Github. Ok. If you read farther down the page then it looks like Boost-CMake really _is_ going to be resurrected in the future? Is there any current activity with respect to Boost and git and cmake? I am so confused. I was going to take over for Troy S. in getting Boost-CMake ready after each release but if there is "Official" work doing this then I am not going to waste me time. Clarifications would be wonderful at this point. Thanks Mike Jackson
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 8/26/2010 12:12 PM, Michael Jackson wrote:
So the boost-svn tracking is now hosted at Github. Ok. If you read farther down the page then it looks like Boost-CMake really _is_ going to be resurrected in the future? Is there any current activity with respect to Boost and git and cmake?
I am so confused. I was going to take over for Troy S. in getting Boost-CMake ready after each release but if there is "Official" work doing this then I am not going to waste me time.
Clarifications would be wonderful at this point.
Let me see if I can clarify. Ryppl is a project started by Dave Abrahams and Troy to simplify and streamline software development, deployment, testing and reporting. It supports Git and CMake natively. Dave A and I are actively working on it. I have also been maintaining a CMake-able and modularized version of Boost (work started by Troy). The guys from Kitware (of CMake fame) want to see this happen too and have been supporting us, making fixes to the CMake files as needed. The vision is that each boost library lives in its own Git repo and states what other libraries it depends on. "boost" then is just another library that depends on a bunch of other libraries. Building and installing Boost is then a matter of making local clones of all the git repos and using cmake to build and install. But ryppl's scope extends beyond boost. There is a project index much like pypi where people can upload and download "packages" (really just links to git repos). Much of this is already working, but we still have a long way to go. What does this all mean for the Boost-CMake fork? Not much in the short term. Ryppl is a long-term project. Even if we achieve our vision, it's not clear that Boost as an organization will adopt it. So don't stop your Boost-CMake work. It works today and meets a real need. Feel free to join the ryppl mailing list or drop by on irc. All that information can be found on ryppl.org. Cheers, - -- Eric Niebler BoostPro Computing http://www.boostpro.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMdqdaAAoJEAeJsEDfjLbXwkAH/3fYccu7RVjB7kN+RhkzMunl pRp62LnTH3tb2+TwYqksON4cwIDZjBKqh/YhI6kumBulMqZE20HS8PV1w7Z24UV3 +zZPiJz0omXHeSYNxe64i3dixt23LOqa1S4D9sYK/hkwgwXqlWiiR+kOq38u4MV5 VzvivDV8X2keaF63SZqvRvAum6fi1KI9gp+wbhAVOUWXXoctLvPtqAcL51vGFm+S P3UUQ/jA9Xi7bHNazNtnIQmHLrrK1sHHZRzGVSyxOhh4qJW1DYU8RBSWpLBlEDLS 1JKA1mcFCLEcF9MKSY2O7lX70KMyAzMd9DdcmhKpitfZ4MfChheGjGCY0pJSQ5A= =s3L/ -----END PGP SIGNATURE-----
At Thu, 26 Aug 2010 13:41:46 -0400, Eric Niebler wrote:
Even if we achieve our vision, it's not clear that Boost as an organization will adopt it.
<ahem> A small correction: even *when* we achieve our vision, there's no *guarantee* that Boost will adopt it. [But Boost will adopt it. Just promise not to sue us in case they don't :-)] -- Dave Abrahams BoostPro Computing http://www.boostpro.com
David Abrahams wrote:
At Thu, 26 Aug 2010 13:41:46 -0400, Eric Niebler wrote:
Even if we achieve our vision, it's not clear that Boost as an organization will adopt it.
<ahem>
A small correction: even *when* we achieve our vision, there's no *guarantee* that Boost will adopt it.
[But Boost will adopt it. Just promise not to sue us in case they don't :-)]
I find the above statement to be a very interesting advertisement approach for a project that addresses requirements that were never discussed on this list, and which itself was never discussed much. In fact, this statement sounds like you have made some secret arrangements (*), or even that you had some revelation from supernatural powers -- which is probably not what you was going to communicate. I think Eric statement is much more balanced. - Volodya (*) In fact, ryppl gave an impression of some secret arrangements from the very start.
On Sat, 28 Aug 2010 11:12:49 +0400
Vladimir Prus
David Abrahams wrote:
At Thu, 26 Aug 2010 13:41:46 -0400, Eric Niebler wrote:
Even if we achieve our vision, it's not clear that Boost as an organization will adopt it.
<ahem>
A small correction: even *when* we achieve our vision, there's no *guarantee* that Boost will adopt it.
[But Boost will adopt it. Just promise not to sue us in case they don't :-)]
[snip..]
I think Eric statement is much more balanced.
+1 In the spirit of Boost openness, re adoption of libraries, technologies, or whatever, I have to agree with Vladimir's perceptions, and equally accurate statement that Eric's line was /much more balanced/ Cheers, -- Manfred
On 8/28/2010 3:12 AM, Vladimir Prus wrote:
David Abrahams wrote:
At Thu, 26 Aug 2010 13:41:46 -0400, Eric Niebler wrote:
Even if we achieve our vision, it's not clear that Boost as an organization will adopt it.
<ahem>
A small correction: even *when* we achieve our vision, there's no *guarantee* that Boost will adopt it.
[But Boost will adopt it. Just promise not to sue us in case they don't :-)]
I find the above statement to be a very interesting advertisement approach for a project that addresses requirements that were never discussed on this list, and which itself was never discussed much. In fact, this statement sounds like you have made some secret arrangements (*), or even that you had some revelation from supernatural powers -- which is probably not what you was going to communicate.
I think Eric statement is much more balanced.
- Volodya
(*) In fact, ryppl gave an impression of some secret arrangements from the very start.
Dave was expressing confidence about the value of our work, no more. There have been no secrets and no back-room negotiations. Boost's scalability problems have been discussed endlessly here and in open sessions at BoostCon, but no decisions about Boost's future were made or will be made by fiat. Boost doesn't work that way. It's true that the requirements of, or even the need for, ryppl was not debated here on this list. But that's how most Boost libraries start. Someone has a vision and builds a thing. Then they bring it to Boost and it's improved and accepted or rejected. Trying to get quorum on a thing that isn't built yet is just hard. "If you build it, they will come" -- so we hope. We're building ryppl because we think the development community (not just Boost) could benefit from it. We're building it in the open. The mailing list is public, our design and vision are published, we're gladly accepting feedback and patches. We're working hard to make ryppl support the scenarios that are important to Boost, so I have high personal hopes that when it's ready Boost will adopt it. But that will be left up to the community. -- Eric Niebler BoostPro Computing http://www.boostpro.com
participants (5)
-
David Abrahams -
Eric Niebler -
Manfred Doudar -
Michael Jackson -
Vladimir Prus