boost modularisation status?
https://svn.boost.org/trac/boost/wiki/CMakeModularizationStatus hasn't been modified in 3 years. Also, when I peruse my local copy of the release tree, I don't see what I expect to see according to https://svn.boost.org/trac/boost/wiki/CMakeModularizeLibrary That is, I expect to seem include inside of the libraries at boost/libs/tr1/include - I don't see this. What is the current status of this? Robert Ramey
On 12/31/2011 08:08 PM, Robert Ramey wrote:
https://svn.boost.org/trac/boost/wiki/CMakeModularizationStatus
hasn't been modified in 3 years.
Also, when I peruse my local copy of the release tree, I don't see what I expect to see according to https://svn.boost.org/trac/boost/wiki/CMakeModularizeLibrary
That is, I expect to seem include inside of the libraries at boost/libs/tr1/include - I don't see this.
What is the current status of this?
Modularized Boost is available at https://github.com/boost-lib/boost
Mathias Gaunard wrote:
On 12/31/2011 08:08 PM, Robert Ramey wrote:
https://svn.boost.org/trac/boost/wiki/CMakeModularizationStatus
hasn't been modified in 3 years.
Also, when I peruse my local copy of the release tree, I don't see what I expect to see according to https://svn.boost.org/trac/boost/wiki/CMakeModularizeLibrary
That is, I expect to seem include inside of the libraries at boost/libs/tr1/include - I don't see this.
What is the current status of this?
Modularized Boost is available at
OK - this looks interesting to me. A couple of questions: a) I don't see any scripts for testing libraries - how does that work b) I don't see a place where one specifies build parameters, etc. I'm sure its around somewhere. Is there a link to a place where one can find all the information about this alternative system? Robert Ramey
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
on Sat Dec 31 2011, "Robert Ramey" <ramey-AT-rrsd.com> wrote:
https://svn.boost.org/trac/boost/wiki/CMakeModularizationStatus
hasn't been modified in 3 years.
Also, when I peruse my local copy of the release tree, I don't see what I expect to see according to https://svn.boost.org/trac/boost/wiki/CMakeModularizeLibrary
That is, I expect to seem include inside of the libraries at boost/libs/tr1/include - I don't see this.
What is the current status of this?
Glad you asked! That wiki page is (fortunately) out of date. We currently have an automated process modularizing boost each time there's a new commit. It uses this script <http://github.com/ryppl/boost-modularize> which you can see at <https://github.com/ryppl/boost-modularize/commits> is being kept up-to-date by Daniel Pfeifer. You can view the status right here: http://j.mp/boost-modularization-bot [1] (if you see many or all of the buildslaves offline it's because I'm reorganizing things a bit at the moment) What you're seeing in the right-hand column is the modularization process itself: it's operating on a mirror of the Boost SVN, and splitting up the files into separate git repositories (at https://github.com/boost-lib) according to their respective projects. If that column is green, it tells you that all files are currently accounted for. Here's what happens if there are files that don't have a known modularization home: http://j.mp/boost-modularization-failure [2] (In that run, it looks like someone just added the Boost.Heap library and it needed to be accounted for). When that happens, Daniel get an email and he fixes it. The other columns represent the results of Boost "integration tests" on the modularized state. An integration test is essentially equivalent to what we're doing today for Boost: run all of the libraries' tests together. Each time there's a new modularization, integration testing is done on several platforms. Now, the reason those columns are not all green is that a bunch of libraries have not had their tests and documentation builds ported to CMake yet. Daniel has opened a ticket for each one of those: https://github.com/ryppl/boost-modularize/issues Most of these should be really straightforward to handle. For examples of test CMake files, have a look at the commits that closed these issues: http://j.mp/cmake-ified-boost-tests [3] ,----[ You can Help ] | It would be great to close more of these issues. Most should be very easy. `---- Ravikiran Rajagopal graciously ported the Python tests, which are among the most complex because they have to invoke Python instead of just building and running C++ executables (<https://github.com/boost-lib/python/blob/master/test/CMakeLists.txt>). Footnotes: [1] <http://bbot.boostpro.com/waterfall?show_events=true&builder=Boost-vc8-win64-Integration&builder=Boost-vc7.1-win64-Integration&builder=Boost-gcc-linux-Integration&builder=Boost-vc10-win64-Integration&builder=Boost-vc9-win64-Integration&builder=Boost.Modularize-x-Modularize&reload=none> [2] <http://bbot.boostpro.com/builders/Boost.Modularize-x-Modularize/builds/1343/steps/modularize%28update%29/logs/stdio> [3] <https://github.com/ryppl/boost-modularize/issues/search?q=unit+tests&state=closed> -- Dave Abrahams BoostPro Computing http://www.boostpro.com
on Sat Dec 31 2011, Dave Abrahams <dave-AT-boostpro.com> wrote:
on Sat Dec 31 2011, "Robert Ramey" <ramey-AT-rrsd.com> wrote:
https://svn.boost.org/trac/boost/wiki/CMakeModularizationStatus
hasn't been modified in 3 years.
Also, when I peruse my local copy of the release tree, I don't see what I expect to see according to https://svn.boost.org/trac/boost/wiki/CMakeModularizeLibrary
That is, I expect to seem include inside of the libraries at boost/libs/tr1/include - I don't see this.
What is the current status of this?
Glad you asked!
That wiki page is (fortunately) out of date.
I've updated the Wiki page now. Please let me know what you think. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On 12/31/2011 5:37 PM, Dave Abrahams wrote:
on Sat Dec 31 2011, Dave Abrahams <dave-AT-boostpro.com> wrote:
on Sat Dec 31 2011, "Robert Ramey" <ramey-AT-rrsd.com> wrote:
https://svn.boost.org/trac/boost/wiki/CMakeModularizationStatus hasn't been modified in 3 years.
Also, when I peruse my local copy of the release tree, I don't see what I expect to see according to https://svn.boost.org/trac/boost/wiki/CMakeModularizeLibrary
This page also needs to be updated or deleted.
That is, I expect to seem include inside of the libraries at boost/libs/tr1/include - I don't see this.
What is the current status of this?
Glad you asked!
That wiki page is (fortunately) out of date.
I've updated the Wiki page now. Please let me know what you think.
I for one am glad to see this effort is ongoing. I'd like to see this project get more visibility as I see it as important for the long-term health of Boost. Can we put something on boost.org encouraging people to try out the (pre-alpha) modularlized boost distro, where to file bugs and how to get involved, etc? -- Eric Niebler BoostPro Computing http://www.boostpro.com
Le 01/01/12 20:51, Eric Niebler a écrit :
On 12/31/2011 5:37 PM, Dave Abrahams wrote:
on Sat Dec 31 2011, Dave Abrahams<dave-AT-boostpro.com> wrote:
on Sat Dec 31 2011, "Robert Ramey"<ramey-AT-rrsd.com> wrote:
https://svn.boost.org/trac/boost/wiki/CMakeModularizationStatus hasn't been modified in 3 years.
Also, when I peruse my local copy of the release tree, I don't see what I expect to see according to https://svn.boost.org/trac/boost/wiki/CMakeModularizeLibrary This page also needs to be updated or deleted.
That is, I expect to seem include inside of the libraries at boost/libs/tr1/include - I don't see this.
What is the current status of this? Glad you asked!
That wiki page is (fortunately) out of date. I've updated the Wiki page now. Please let me know what you think. I for one am glad to see this effort is ongoing. I'd like to see this project get more visibility as I see it as important for the long-term health of Boost. Can we put something on boost.org encouraging people to try out the (pre-alpha) modularlized boost distro, where to file bugs and how to get involved, etc?
Hi, this should be considered as a new tool (and in addition it needs CMAKE build). While I consider the modularization useful, I find that adding a new build system to Boost will need some official maintainers of the CMake files for each one of the Boost libraries until the library authors have taken the time to be familiar with the new build system. Of course, this will imply that we need regular testers for both build systems which will be time consuming Resuming, I think that we need a formal review for CMake build once it is able to build the whole Boost libraries. Is CMake build ready for review? If no, what is missing, not working yet, ...? Best, Vicente
Hi, Sorry if this is a stupid question... I understand the purpose of modularizing the library, but what is the purpose of simultaneously porting the build system from Boost.Build to CMake? Thanks, Nate
on Sun Jan 01 2012, Nathan Ridge <zeratul976-AT-hotmail.com> wrote:
Hi,
Sorry if this is a stupid question...
I understand the purpose of modularizing the library, but what is the purpose of simultaneously porting the build system from Boost.Build to CMake?
Not a stupid question at all. Doing these two things separately might have been a better idea, but that's not the way it has gone. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On Sun, 01 Jan 2012 19:47:29 -0500 Dave Abrahams <dave@boostpro.com> wrote:
Sorry if this is a stupid question...
I understand the purpose of modularizing the library, but what is the purpose of simultaneously porting the build system from Boost.Build to CMake?
Not a stupid question at all. Doing these two things separately might have been a better idea, but that's not the way it has gone.
I for one would never contribute to a project requiring me to use cmake. I'd probably pay more attention to the modularization effort otherwise.
on Sun Jan 01 2012, "Vicente J. Botet Escriba" <vicente.botet-AT-wanadoo.fr> wrote:
Le 01/01/12 20:51, Eric Niebler a écrit :
On 12/31/2011 5:37 PM, Dave Abrahams wrote:
on Sat Dec 31 2011, Dave Abrahams<dave-AT-boostpro.com> wrote:
on Sat Dec 31 2011, "Robert Ramey"<ramey-AT-rrsd.com> wrote:
https://svn.boost.org/trac/boost/wiki/CMakeModularizationStatus hasn't been modified in 3 years.
Also, when I peruse my local copy of the release tree, I don't see what I expect to see according to https://svn.boost.org/trac/boost/wiki/CMakeModularizeLibrary This page also needs to be updated or deleted.
That is, I expect to seem include inside of the libraries at boost/libs/tr1/include - I don't see this.
What is the current status of this? Glad you asked!
That wiki page is (fortunately) out of date. I've updated the Wiki page now. Please let me know what you think. I for one am glad to see this effort is ongoing. I'd like to see this project get more visibility as I see it as important for the long-term health of Boost. Can we put something on boost.org encouraging people to try out the (pre-alpha) modularlized boost distro, where to file bugs and how to get involved, etc?
Hi,
this should be considered as a new tool (and in addition it needs CMAKE build). While I consider the modularization useful, I find that adding a new build system to Boost will need some official maintainers of the CMake files for each one of the Boost libraries until the library authors have taken the time to be familiar with the new build system. Of course, this will imply that we need regular testers for both build systems which will be time consuming
I understand, but I disagree. There's no reason to make the (already high) hurdles to such a transition stratospherically high. If the Boost community decides to use any given new piece of infrastructure, there's no reason it has to be a protracted process; it can just happen.
Resuming, I think that we need a formal review for CMake build once it is able to build the whole Boost libraries.
Again I disagree. The review process is for libraries, and Boost has never formally reviewed tools like this. I am more than happy to have a discussion about it, and I believe that discussion should inform our decision, but I believe it is possible for the steering committee to make a decision as a matter of policy.
Is CMake build ready for review? If no, what is missing, not working yet, ...?
I think the Wiki page makes it pretty darned clear what the status is. Did you read the whole thing (particularly https://svn.boost.org/trac/boost/wiki/CMakeModularizationStatus#TODOs?) -- Dave Abrahams BoostPro Computing http://www.boostpro.com
on Sun Jan 01 2012, "Vicente J. Botet Escriba"<vicente.botet-AT-wanadoo.fr> wrote:
Le 01/01/12 20:51, Eric Niebler a écrit :
On 12/31/2011 5:37 PM, Dave Abrahams wrote:
on Sat Dec 31 2011, Dave Abrahams<dave-AT-boostpro.com> wrote:
on Sat Dec 31 2011, "Robert Ramey"<ramey-AT-rrsd.com> wrote:
https://svn.boost.org/trac/boost/wiki/CMakeModularizationStatus hasn't been modified in 3 years.
Also, when I peruse my local copy of the release tree, I don't see what I expect to see according to https://svn.boost.org/trac/boost/wiki/CMakeModularizeLibrary This page also needs to be updated or deleted.
That is, I expect to seem include inside of the libraries at boost/libs/tr1/include - I don't see this.
What is the current status of this? Glad you asked!
That wiki page is (fortunately) out of date. I've updated the Wiki page now. Please let me know what you think. I for one am glad to see this effort is ongoing. I'd like to see this project get more visibility as I see it as important for the long-term health of Boost. Can we put something on boost.org encouraging people to try out the (pre-alpha) modularlized boost distro, where to file bugs and how to get involved, etc?
Hi,
this should be considered as a new tool (and in addition it needs CMAKE build). While I consider the modularization useful, I find that adding a new build system to Boost will need some official maintainers of the CMake files for each one of the Boost libraries until the library authors have taken the time to be familiar with the new build system. Of course, this will imply that we need regular testers for both build systems which will be time consuming I understand, but I disagree. There's no reason to make the (already high) hurdles to such a transition stratospherically high. If the Boost community decides to use any given new piece of infrastructure, there's no reason it has to be a protracted process; it can just happen. Does this means that the library authors will need to maintain two build systems? Resuming, I think that we need a formal review for CMake build once it is able to build the whole Boost libraries. Again I disagree. The review process is for libraries, and Boost has never formally reviewed tools like this. I am more than happy to have a discussion about it, and I believe that discussion should inform our decision, but I believe it is possible for the steering committee to make a decision as a matter of policy. Oh, as lastly we have started to review also the tools I thought it works like that also for a new build system, but you know better how Boost works. I think it is time to start this discussion. Please could
Le 02/01/12 01:44, Dave Abrahams a écrit : the interested parties start a thread that results once for all in a decision on whether CMake based build is adopted or not?
Is CMake build ready for review? If no, what is missing, not working yet, ...? I think the Wiki page makes it pretty darned clear what the status is. Did you read the whole thing (particularly https://svn.boost.org/trac/boost/wiki/CMakeModularizationStatus#TODOs?)
No, I didn't read it before. I've read it now. I see that there is yet some work to do yet. If the library authors should maintain the CMake build system they could participate in the writing of these CMake files, of course once the Boost community decide to adopt the new build system. Note that I'm not completely against the adoption of CMake, as it could have some advantages, but the liabilities should be considered also when the decision will be taken. For that we need to start a discussion, goals, documentation, who will take the decision, .... Best, Vicente
On 1/1/2012 8:23 PM, Vicente J. Botet Escriba wrote:
Note that I'm not completely against the adoption of CMake, as it could have some advantages, but the liabilities should be considered also when the decision will be taken. For that we need to start a discussion, goals, documentation, who will take the decision, ....
Have you read the previous, as in previous few years, of discussions about cmake vs. b2? -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
Date: Sun, 1 Jan 2012 20:34:15 -0600 From: grafikrobot@gmail.com To: boost@lists.boost.org Subject: Re: [boost] boost modularisation status?
On 1/1/2012 8:23 PM, Vicente J. Botet Escriba wrote:
Note that I'm not completely against the adoption of CMake, as it could have some advantages, but the liabilities should be considered also when the decision will be taken. For that we need to start a discussion, goals, documentation, who will take the decision, ....
Have you read the previous, as in previous few years, of discussions about cmake vs. b2?
Could someone with links to these discussions be kind enough to post them? I would like to read them as well. Thanks, Nate
on Sun Jan 01 2012, "Vicente J. Botet Escriba" <vicente.botet-AT-wanadoo.fr> wrote:
Hi,
this should be considered as a new tool (and in addition it needs CMAKE build). While I consider the modularization useful, I find that adding a new build system to Boost will need some official maintainers of the CMake files for each one of the Boost libraries until the library authors have taken the time to be familiar with the new build system. Of course, this will imply that we need regular testers for both build systems which will be time consuming
I understand, but I disagree. There's no reason to make the (already high) hurdles to such a transition stratospherically high. If the Boost community decides to use any given new piece of infrastructure, there's no reason it has to be a protracted process; it can just happen.
Does this means that the library authors will need to maintain two build systems?
No, that would be bad, IMO. My point was that we should not let ourselves get into such an intermediate state.
Resuming, I think that we need a formal review for CMake build once it is able to build the whole Boost libraries.
Again I disagree. The review process is for libraries, and Boost has never formally reviewed tools like this. I am more than happy to have a discussion about it, and I believe that discussion should inform our decision, but I believe it is possible for the steering committee to make a decision as a matter of policy.
Oh, as lastly we have started to review also the tools
Oh, we have? Maybe I'm not paying enough attention. Could you clarify?
I thought it works like that also for a new build system, but you know better how Boost works. I think it is time to start this discussion. Please could the interested parties start a thread that results once for all in a decision on whether CMake based build is adopted or not?
It's not time to make such a decision, unless we're going to decide "no." The system isn't complete yet. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On 1/1/2012 6:44 PM, Dave Abrahams wrote:
The review process is for libraries, and Boost has never formally reviewed tools like this.
As of the indexing tool we do have reviews for tools. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
on Sun Jan 01 2012, Rene Rivera <grafikrobot-AT-gmail.com> wrote:
On 1/1/2012 6:44 PM, Dave Abrahams wrote:
The review process is for libraries, and Boost has never formally reviewed tools like this.
As of the indexing tool we do have reviews for tools.
Sorry... what's the indexing tool? I must have been sleeping. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On 2 January 2012 15:33, Dave Abrahams <dave@boostpro.com> wrote:
on Sun Jan 01 2012, Rene Rivera <grafikrobot-AT-gmail.com> wrote:
On 1/1/2012 6:44 PM, Dave Abrahams wrote:
The review process is for libraries, and Boost has never formally reviewed tools like this.
As of the indexing tool we do have reviews for tools.
Sorry... what's the indexing tool? I must have been sleeping.
Vicente J. Botet Escriba wrote:
this should be considered as a new tool (and in addition it needs CMAKE build). While I consider the modularization useful, I find that adding a new build system to Boost will need some official maintainers of the CMake files for each one of the Boost libraries until the library authors have taken the time to be familiar with the new build system. Of course, this will imply that we need regular testers for both build systems which will be time consuming
Resuming, I think that we need a formal review for CMake build once it is able to build the whole Boost libraries.
Is CMake build ready for review? If no, what is missing, not working yet, ...?
I was interested in modularization because I wanted to make a small library and have it self contained so it doesn't have to be in the boost tree, but would have that option in the future. Then I came upon the cmake stuff and asked the question. Then I thought I remembered that the cmake stuff was in the boost tree but when I looked I didn't find it there. I found it in the GIT tree. So as things stand now, cmake build/test of boost is not part part of boost itself. It's not a required tool. So I can't see why a review would be necessary. What if it fails the review - would I be prevented from using it on my own machine? If things evolve and a significant number of people start to prefer it over the current system, we can look at the issue as to whether we have to choose and if so what should we choose. a totally separate issue - the GIT tree seems to clone the trunk - wouldn't it be better if it cloned the release branch? Robert Ramey
on Sun Jan 01 2012, "Robert Ramey" <ramey-AT-rrsd.com> wrote:
So as things stand now, cmake build/test of boost is not part part of boost itself. It's not a required tool. So I can't see why a review would be necessary.
It might be necessary if Boost were going to adopt it as the official system. I certainly won't want to maintain it forever if Boost were _not_ going to adopt it.
What if it fails the review - would I be prevented from using it on my own machine?
How could anyone prevent that?
If things evolve and a significant number of people start to prefer it over the current system, we can look at the issue as to whether we have to choose and if so what should we choose.
I really don't want that to happen. When the system is completed I hope we'll have an evaluation period and make a decision quickly.
a totally separate issue - the GIT tree seems to clone the trunk - wouldn't it be better if it cloned the release branch?
I don't think so. The point of the project as we currently have it is to prove that we can port the latest in-development state of Boost to the new system without interruption when the system is complete. If we only worked on the release branch we would have massive disruption and breakage every time Boost made a new release and no activity at any other time. When the transition is finally completed, we'll preserve all Boost branches in the Git repository. You can see the release branch in an un-modularized Boost Git repo here: https://github.com/ryppl/boost-svn/tree/release -- Dave Abrahams BoostPro Computing http://www.boostpro.com
on Sun Jan 01 2012, Eric Niebler <eric-AT-boostpro.com> wrote:
On 12/31/2011 5:37 PM, Dave Abrahams wrote:
on Sat Dec 31 2011, Dave Abrahams <dave-AT-boostpro.com> wrote:
on Sat Dec 31 2011, "Robert Ramey" <ramey-AT-rrsd.com> wrote:
https://svn.boost.org/trac/boost/wiki/CMakeModularizationStatus hasn't been modified in 3 years.
Also, when I peruse my local copy of the release tree, I don't see what I expect to see according to https://svn.boost.org/trac/boost/wiki/CMakeModularizeLibrary
This page also needs to be updated or deleted.
That is, I expect to seem include inside of the libraries at boost/libs/tr1/include - I don't see this.
What is the current status of this?
Glad you asked!
That wiki page is (fortunately) out of date.
I've updated the Wiki page now. Please let me know what you think.
I for one am glad to see this effort is ongoing. I'd like to see this project get more visibility as I see it as important for the long-term health of Boost. Can we put something on boost.org encouraging people to try out the (pre-alpha) modularlized boost distro, where to file bugs and how to get involved, etc?
Please go ahead! I'd like to see that happen too. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On 1/1/2012 4:33 PM, Dave Abrahams wrote:
on Sun Jan 01 2012, Eric Niebler <eric-AT-boostpro.com> wrote:
I for one am glad to see this effort is ongoing. I'd like to see this project get more visibility as I see it as important for the long-term health of Boost. Can we put something on boost.org encouraging people to try out the (pre-alpha) modularlized boost distro, where to file bugs and how to get involved, etc?
Please go ahead! I'd like to see that happen too.
:-) I served my time on that project. Now I'm just a cheerleader. Feel free to take or leave my suggestion. -- Eric Niebler BoostPro Computing http://www.boostpro.com
on Sun Jan 01 2012, Eric Niebler <eric-AT-boostpro.com> wrote:
On 1/1/2012 4:33 PM, Dave Abrahams wrote:
on Sun Jan 01 2012, Eric Niebler <eric-AT-boostpro.com> wrote:
I for one am glad to see this effort is ongoing. I'd like to see this project get more visibility as I see it as important for the long-term health of Boost. Can we put something on boost.org encouraging people to try out the (pre-alpha) modularlized boost distro, where to file bugs and how to get involved, etc?
Please go ahead! I'd like to see that happen too.
:-) I served my time on that project. Now I'm just a cheerleader. Feel free to take or leave my suggestion.
I appreciate your contribution very much, but seriously, nobody's asking you to write code.(**) Putting "something on boost.org encouraging people to try out the (pre-alpha) modularlized boost distro, where to file bugs and how to get involved, etc" doesn't go much beyond cheerleading. Could you at least make some suggestion of where a notice like that belongs? (**) we don't count HTML as code here, do we? -- Dave Abrahams BoostPro Computing http://www.boostpro.com
participants (9)
-
Daniel James -
Dave Abrahams -
Eric Niebler -
Mathias Gaunard -
Nathan Ridge -
Rene Rivera -
Robert Ramey -
Sergey Popov -
Vicente J. Botet Escriba