Boost Modularization: did we get it right?
Hi All, As we head toward a modularized Boost, Daniel Pfeifer we on the Ryppl project would like confirmation that we've correctly (or at least sensibly, when there's no obvious "correct") identified the module boundaries in Boost's monolithic SVN repository. If library authors could take a few moments to examine the contents of your library's repo at https://github.com/boost-lib, and let us know, we'd be most grateful. Thanks! -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On 08.05.2012 13:44, Dave Abrahams wrote:
Hi All,
As we head toward a modularized Boost, Daniel Pfeifer we on the Ryppl project would like confirmation that we've correctly (or at least sensibly, when there's no obvious "correct") identified the module boundaries in Boost's monolithic SVN repository. If library authors could take a few moments to examine the contents of your library's repo at https://github.com/boost-lib, and let us know, we'd be most grateful.
PropertyTree looks fine. Sebastian
Dave Abrahams wrote
As we head toward a modularized Boost, Daniel Pfeifer we on the Ryppl project would like confirmation that we've correctly (or at least sensibly, when there's no obvious "correct") identified the module boundaries in Boost's monolithic SVN repository. If library authors could take a few moments to examine the contents of your library's repo at https://github.com/boost-lib, and let us know, we'd be most grateful.
ScopeExit, LocalFunction, Utility/IdentityType, and Functional/OverloadedFunction look good. Thanks. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/Boost-Modularization-did-we-get-it-right-... Sent from the Boost - Dev mailing list archive at Nabble.com.
On 5/8/2012 7:44 PM, Dave Abrahams wrote:
Hi All,
As we head toward a modularized Boost, Daniel Pfeifer we on the Ryppl project would like confirmation that we've correctly (or at least sensibly, when there's no obvious "correct") identified the module boundaries in Boost's monolithic SVN repository. If library authors could take a few moments to examine the contents of your library's repo at https://github.com/boost-lib, and let us know, we'd be most grateful.
Fusion + Spirit + Phoenix look good. When can we use it? Regards, -- Joel de Guzman http://www.boostpro.com http://boost-spirit.com
on Tue May 08 2012, Joel de Guzman <joel-AT-boost-consulting.com> wrote:
On 5/8/2012 7:44 PM, Dave Abrahams wrote:
Hi All,
As we head toward a modularized Boost, Daniel Pfeifer we on the Ryppl project would like confirmation that we've correctly (or at least sensibly, when there's no obvious "correct") identified the module boundaries in Boost's monolithic SVN repository. If library authors could take a few moments to examine the contents of your library's repo at https://github.com/boost-lib, and let us know, we'd be most grateful.
Fusion + Spirit + Phoenix look good.
When can we use it?
Now, if you like... depending on what you mean by "use," of course. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
As we head toward a modularized Boost, Daniel Pfeifer we on the Ryppl project would like confirmation that we've correctly (or at least sensibly, when there's no obvious "correct") identified the module boundaries in Boost's monolithic SVN repository. If library authors could take a few moments to examine the contents of your library's repo at https://github.com/boost-lib, and let us know, we'd be most grateful.
I haven't tried to use it, but at first glance the files for regex, math, type_traits, TR1 and integer all look right. No doubt all the relative paths in the docs will be wrong though (if they have full relative paths to the headers)? HTH, John.
on Tue May 08 2012, John Maddock <boost.regex-AT-virgin.net> wrote:
As we head toward a modularized Boost, Daniel Pfeifer we on the Ryppl project would like confirmation that we've correctly (or at least sensibly, when there's no obvious "correct") identified the module boundaries in Boost's monolithic SVN repository. If library authors could take a few moments to examine the contents of your library's repo at https://github.com/boost-lib, and let us know, we'd be most grateful.
I haven't tried to use it, but at first glance the files for regex, math, type_traits, TR1 and integer all look right. No doubt all the relative paths in the docs will be wrong though (if they have full relative paths to the headers)?
Probably. That's a good point. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On Tue, May 8, 2012 at 1:23 PM, Dave Abrahams <dave@boostpro.com> wrote:
on Tue May 08 2012, John Maddock <boost.regex-AT-virgin.net> wrote:
As we head toward a modularized Boost, Daniel Pfeifer we on the Ryppl project would like confirmation that we've correctly (or at least sensibly, when there's no obvious "correct") identified the module boundaries in Boost's monolithic SVN repository. If library authors could take a few moments to examine the contents of your library's repo at https://github.com/boost-lib, and let us know, we'd be most grateful.
I haven't tried to use it, but at first glance the files for regex, math, type_traits, TR1 and integer all look right. No doubt all the relative paths in the docs will be wrong though (if they have full relative paths to the headers)?
Probably. That's a good point.
If you have cmake installed, and install modularized boost: git clone http://github.com/boost-lib/boost boost-modules cd boost-modules git submodule update --init (16 minutes on DSL connection) cmake -P forward_headers.cmake (2 minutes on SSD hard-drive) Then symlinks to headers will be installed in a "boost" sub-tree in the root directory. Your doc links should then work. Caution: forward_headers.cmake was only installed a few hours ago, so you may have to do a pull to get it if you already have done the clone. Caution: On Windows 7, I had to run the cmake step with administrative privileges or forwarding headers were installed rather than symlinks. --Beman
----- Original Message -----
From: Dave Abrahams <dave@boostpro.com> To: boost <boost@lists.boost.org> Cc: Sent: Tuesday, May 8, 2012 2:44 PM Subject: [boost] Boost Modularization: did we get it right?
Hi All,
As we head toward a modularized Boost, Daniel Pfeifer we on the Ryppl project would like confirmation that we've correctly (or at least sensibly, when there's no obvious "correct") identified the module boundaries in Boost's monolithic SVN repository. If library authors could take a few moments to examine the contents of your library's repo at https://github.com/boost-lib, and let us know, we'd be most grateful.
Thanks!
-- Dave Abrahams BoostPro Computing http://www.boostpro.com
Boost.Locale is 100% ok BTW does this mean that CMake would be soon our official build system as well? (AMEN) Artyom Beilis -------------- CppCMS - C++ Web Framework: http://cppcms.com/ CppDB - C++ SQL Connectivity: http://cppcms.com/sql/cppdb/
On Tue, 8 May 2012, Dave Abrahams wrote:
Hi All,
As we head toward a modularized Boost, Daniel Pfeifer we on the Ryppl project would like confirmation that we've correctly (or at least sensibly, when there's no obvious "correct") identified the module boundaries in Boost's monolithic SVN repository. If library authors could take a few moments to examine the contents of your library's repo at https://github.com/boost-lib, and let us know, we'd be most grateful.
graph and graph_parallel are fine; property_map is reasonable except that the things that are in include/boost/pending should be in that directory in graph/ instead. Does it make sense to modularize utility to split things like enable_if out into separate trees like you are doing at the top level of Boost? -- Jeremiah Willcock
On Tue, May 8, 2012 at 12:15 PM, Jeremiah Willcock <jewillco@osl.iu.edu> wrote:
On Tue, 8 May 2012, Dave Abrahams wrote:
Hi All,
As we head toward a modularized Boost, Daniel Pfeifer we on the Ryppl project would like confirmation that we've correctly (or at least sensibly, when there's no obvious "correct") identified the module boundaries in Boost's monolithic SVN repository. If library authors could take a few moments to examine the contents of your library's repo at https://github.com/boost-lib, and let us know, we'd be most grateful.
graph and graph_parallel are fine; property_map is reasonable except that the things that are in include/boost/pending should be in that directory in graph/ instead. Does it make sense to modularize utility to split things like enable_if out into separate trees like you are doing at the top level of Boost?
Daniel Pfeifer and the other Ryppl folks have already done a some minor rationalization where a few minor components were clearly in the wrong spot. See boost-root/libs/core. Utility may well need some further refactoring, which can take the form of additional sub-directories as well as additional sub-modules. Years ago John Maddock had some guidelines on directory tree branchiness. The idea was that both too few and too many were less than helpful. I'm guessing sub-modules are similar - too few and the full benefits of modularization are not obtained, too many and confusion or other costs may overwhelm benefits. --Beman
2012/5/8 Jeremiah Willcock <jewillco@osl.iu.edu>:
graph and graph_parallel are fine; property_map is reasonable except that the things that are in include/boost/pending should be in that directory in graph/ instead. Does it make sense to modularize utility to split things like enable_if out into separate trees like you are doing at the top level of Boost?
Jeremiah, could you please have a look at the modularization manifest file? https://github.com/ryppl/boost-modularize/blob/master/manifest.txt As you see, boost/pending is split across several modules. Should everything be part of graph instead? cheers, Daniel
On Wed, 9 May 2012, Daniel Pfeifer wrote:
2012/5/8 Jeremiah Willcock <jewillco@osl.iu.edu>:
graph and graph_parallel are fine; property_map is reasonable except that the things that are in include/boost/pending should be in that directory in graph/ instead. Does it make sense to modularize utility to split things like enable_if out into separate trees like you are doing at the top level of Boost?
Jeremiah,
could you please have a look at the modularization manifest file? https://github.com/ryppl/boost-modularize/blob/master/manifest.txt
As you see, boost/pending is split across several modules. Should everything be part of graph instead?
All of boost/pending in property_map should be moved to graph, other than maybe cstddef.hpp, which might go to core or somewhere. Otherwise, boost/pending seems to me to be split up correctly. -- Jeremiah Willcock
2012/5/9 Jeremiah Willcock <jewillco@osl.iu.edu>:
On Wed, 9 May 2012, Daniel Pfeifer wrote:
2012/5/8 Jeremiah Willcock <jewillco@osl.iu.edu>:
graph and graph_parallel are fine; property_map is reasonable except that the things that are in include/boost/pending should be in that directory in graph/ instead. Does it make sense to modularize utility to split things like enable_if out into separate trees like you are doing at the top level of Boost?
Jeremiah,
could you please have a look at the modularization manifest file? https://github.com/ryppl/boost-modularize/blob/master/manifest.txt
As you see, boost/pending is split across several modules. Should everything be part of graph instead?
All of boost/pending in property_map should be moved to graph, other than maybe cstddef.hpp, which might go to core or somewhere. Otherwise, boost/pending seems to me to be split up correctly.
Done.
-- Jeremiah Willcock
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
on Tue May 08 2012, Jeremiah Willcock <jewillco-AT-osl.iu.edu> wrote:
Does it make sense to modularize utility to split things like enable_if out into separate trees like you are doing at the top level of Boost?
Those have documentation together, so IMO it doesn't make sense to split them up at least until after initial modularization. We're trying to do what we can script initially, and that kind of change requires too much user intervention. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On 8 May 2012 12:44, Dave Abrahams <dave@boostpro.com> wrote:
Hi All,
As we head toward a modularized Boost, Daniel Pfeifer we on the Ryppl project would like confirmation that we've correctly (or at least sensibly, when there's no obvious "correct") identified the module boundaries in Boost's monolithic SVN repository. If library authors could take a few moments to examine the contents of your library's repo at https://github.com/boost-lib, and let us know, we'd be most grateful.
My bits looks fine, but if possible I'd like functional/hash to be a separate module from functional (I think that's just everything from the hash subdirectory, with the headers from include/boost/functional/hash*). I guess it's tricky with the way submodules are currently used.
AMDG On 05/08/2012 10:10 AM, Daniel James wrote:
On 8 May 2012 12:44, Dave Abrahams <dave@boostpro.com> wrote:
As we head toward a modularized Boost, Daniel Pfeifer we on the Ryppl project would like confirmation that we've correctly (or at least sensibly, when there's no obvious "correct") identified the module boundaries in Boost's monolithic SVN repository. If library authors could take a few moments to examine the contents of your library's repo at https://github.com/boost-lib, and let us know, we'd be most grateful.
My bits looks fine, but if possible I'd like functional/hash to be a separate module from functional (I think that's just everything from the hash subdirectory, with the headers from include/boost/functional/hash*). I guess it's tricky with the way submodules are currently used.
The same would go for numeric. numeric/ublas, numeric/conversion, and numeric/interval are three independent libraries. In Christ, Steven Watanabe
2012/5/10 Steven Watanabe <watanabesj@gmail.com>:
AMDG
On 05/08/2012 10:10 AM, Daniel James wrote:
On 8 May 2012 12:44, Dave Abrahams <dave@boostpro.com> wrote:
As we head toward a modularized Boost, Daniel Pfeifer we on the Ryppl project would like confirmation that we've correctly (or at least sensibly, when there's no obvious "correct") identified the module boundaries in Boost's monolithic SVN repository. If library authors could take a few moments to examine the contents of your library's repo at https://github.com/boost-lib, and let us know, we'd be most grateful.
My bits looks fine, but if possible I'd like functional/hash to be a separate module from functional (I think that's just everything from the hash subdirectory, with the headers from include/boost/functional/hash*). I guess it's tricky with the way submodules are currently used.
The same would go for numeric.
numeric/ublas, numeric/conversion, and numeric/interval are three independent libraries.
Done. I named them numeric_conversion, numeric_interval, and ublas.
In Christ, Steven Watanabe
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
2012/5/8 Daniel James <dnljms@gmail.com>:
On 8 May 2012 12:44, Dave Abrahams <dave@boostpro.com> wrote:
Hi All,
As we head toward a modularized Boost, Daniel Pfeifer we on the Ryppl project would like confirmation that we've correctly (or at least sensibly, when there's no obvious "correct") identified the module boundaries in Boost's monolithic SVN repository. If library authors could take a few moments to examine the contents of your library's repo at https://github.com/boost-lib, and let us know, we'd be most grateful.
My bits looks fine, but if possible I'd like functional/hash to be a separate module from functional (I think that's just everything from the hash subdirectory, with the headers from include/boost/functional/hash*). I guess it's tricky with the way submodules are currently used.
Done. functional_hash now is a module on its own. That changed the current directory layout. cheers, Daniel
On Tue, May 8, 2012 at 7:44 AM, Dave Abrahams <dave@boostpro.com> wrote:
Hi All,
As we head toward a modularized Boost, Daniel Pfeifer we on the Ryppl project would like confirmation that we've correctly (or at least sensibly, when there's no obvious "correct") identified the module boundaries in Boost's monolithic SVN repository. If library authors could take a few moments to examine the contents of your library's repo at https://github.com/boost-lib, and let us know, we'd be most grateful.
Filesystem looks fine on Windows 7. After installing the forwarding header symlinks: * bootstrap successfully built bjam and b2. * Filesystem passed all tests with bjam. * Filesystem passed all tests run with the VC++ 2010 solution found in boost-root/libs/filesystem/test/msvc10 --Beman
AMDG On 05/08/2012 04:44 AM, Dave Abrahams wrote:
As we head toward a modularized Boost, Daniel Pfeifer we on the Ryppl project would like confirmation that we've correctly (or at least sensibly, when there's no obvious "correct") identified the module boundaries in Boost's monolithic SVN repository. If library authors could take a few moments to examine the contents of your library's repo at https://github.com/boost-lib, and let us know, we'd be most grateful.
Units and Random look okay. In Christ, Steven Watanabe
Dave Abrahams wrote:
Hi All,
As we head toward a modularized Boost, Daniel Pfeifer we on the Ryppl project would like confirmation that we've correctly (or at least sensibly, when there's no obvious "correct") identified the module boundaries in Boost's monolithic SVN repository. If library authors could take a few moments to examine the contents of your library's repo at https://github.com/boost-lib, and let us know, we'd be most grateful.
Hmmm I'm not sure how it's supposed to look. But here is what I see. boost/strongtypedef.hpp was movied to boost/serialization/strongtypedef quite a while ago. It seems we left it in the old place as well so I would expect it should be removed from there. Note that it's possible that this might break some code which is probably the correct thing in this case - and it's trival to fix. I'm intrigued that there's a directory/file util/test.jam while in the test directory there is a Jamfile.v2 . I'm not sure how this is supposed to be, just thought I'd mention it. Robert Ramey
Thanks!
On 08/05/12 12:44, Dave Abrahams wrote:
As we head toward a modularized Boost, Daniel Pfeifer we on the Ryppl project would like confirmation that we've correctly (or at least sensibly, when there's no obvious "correct") identified the module boundaries in Boost's monolithic SVN repository. If library authors could take a few moments to examine the contents of your library's repo at https://github.com/boost-lib, and let us know, we'd be most grateful.
Thread looks OK. Anthony -- Author of C++ Concurrency in Action http://www.stdthread.co.uk/book/ just::thread C++11 thread library http://www.stdthread.co.uk Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976
MultiArray looks good to me. On May 8, 2012, at 7:44 AM, Dave Abrahams wrote:
Hi All,
As we head toward a modularized Boost, Daniel Pfeifer we on the Ryppl project would like confirmation that we've correctly (or at least sensibly, when there's no obvious "correct") identified the module boundaries in Boost's monolithic SVN repository. If library authors could take a few moments to examine the contents of your library's repo at https://github.com/boost-lib, and let us know, we'd be most grateful.
Thanks!
-- Dave Abrahams BoostPro Computing http://www.boostpro.com
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Tue, May 8, 2012, at 07:44 AM, Dave Abrahams wrote:
Hi All,
As we head toward a modularized Boost, Daniel Pfeifer we on the Ryppl project would like confirmation that we've correctly (or at least sensibly, when there's no obvious "correct") identified the module boundaries in Boost's monolithic SVN repository. If library authors could take a few moments to examine the contents of your library's repo at https://github.com/boost-lib, and let us know, we'd be most grateful.
Uuid look fine. Regards, Andy Tompkins
Le 08/05/12 13:44, Dave Abrahams a écrit :
Hi All,
As we head toward a modularized Boost, Daniel Pfeifer we on the Ryppl project would like confirmation that we've correctly (or at least sensibly, when there's no obvious "correct") identified the module boundaries in Boost's monolithic SVN repository. If library authors could take a few moments to examine the contents of your library's repo at https://github.com/boost-lib, and let us know, we'd be most grateful.
Thanks!
Hi, I guess that the answers to these question could be found somewhere, but as we are discussing about whether the split is right or not I would like to have some questions answered explicitly. Which have been the criteria to split the Boost libraries in modulus? Could the dependencies between modulus contain cycles or should we avoid them? Do we have a tool to get the dependencies direct or indirect from a modulo? Best, Vicente
on Sat May 12 2012, "Vicente J. Botet Escriba" <vicente.botet-AT-wanadoo.fr> wrote:
Le 08/05/12 13:44, Dave Abrahams a écrit :
Hi All,
As we head toward a modularized Boost, Daniel Pfeifer we on the Ryppl project would like confirmation that we've correctly (or at least sensibly, when there's no obvious "correct") identified the module boundaries in Boost's monolithic SVN repository. If library authors could take a few moments to examine the contents of your library's repo at https://github.com/boost-lib, and let us know, we'd be most grateful.
Thanks!
Hi,
I guess that the answers to these question could be found somewhere, but as we are discussing about whether the split is right or not I would like to have some questions answered explicitly.
Which have been the criteria to split the Boost libraries in modulus?
Mostly the split has been along the lines of categorization as separate libraries in the library documentation (i.e. "utility" is all one library). However, we've begun making some lower-level split-ups.
Could the dependencies between modulus contain cycles or should we avoid them?
You should avoid them. If avoiding them is impossible, we have a way to deal with it, but in general avoiding them means splitting up some libraries into separate parts, like the part that can be header-only and the part that needs binaries.
Do we have a tool to get the dependencies direct or indirect from a modulo?
https://github.com/ryppl/boost-modularize/blob/master/metadatize.py is what we're using to generate correct dependency information in CMakeLists.txt files. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
Le 21/05/12 18:36, Dave Abrahams a écrit :
on Sat May 12 2012, "Vicente J. Botet Escriba"<vicente.botet-AT-wanadoo.fr> wrote:
Le 08/05/12 13:44, Dave Abrahams a écrit :
Hi All,
As we head toward a modularized Boost, Daniel Pfeifer we on the Ryppl project would like confirmation that we've correctly (or at least sensibly, when there's no obvious "correct") identified the module boundaries in Boost's monolithic SVN repository. If library authors could take a few moments to examine the contents of your library's repo at https://github.com/boost-lib, and let us know, we'd be most grateful.
Thanks!
Hi,
I guess that the answers to these question could be found somewhere, but as we are discussing about whether the split is right or not I would like to have some questions answered explicitly.
Which have been the criteria to split the Boost libraries in modulus? Mostly the split has been along the lines of categorization as separate libraries in the library documentation (i.e. "utility" is all one library). However, we've begun making some lower-level split-ups.
Could the dependencies between modulus contain cycles or should we avoid them? You should avoid them. If avoiding them is impossible, we have a way to deal with it, but in general avoiding them means splitting up some libraries into separate parts, like the part that can be header-only and the part that needs binaries. Have you found some cycles in the current split?
Do we have a tool to get the dependencies direct or indirect from a modulo? https://github.com/ryppl/boost-modularize/blob/master/metadatize.py is what we're using to generate correct dependency information in CMakeLists.txt files.
Could you give a link of the output of this program? Best, Vicente
participants (16)
-
Andy Tompkins -
Anthony Williams -
Artyom Beilis -
Beman Dawes -
Daniel James -
Daniel Pfeifer -
Dave Abrahams -
Jeremiah Willcock -
Joel de Guzman -
John Maddock -
lcaminiti -
Robert Ramey -
Ronald Garcia -
Sebastian Redl -
Steven Watanabe -
Vicente J. Botet Escriba