On 12/7/2012 9:28 AM, Mateusz Loskot wrote:

On 7 December 2012 16:54, Beman Dawes <bdawes@acm.org> wrote:

...

We are starting to pull together documentation for the Git and Modular Boost conversion.

https://svn.boost.org/trac/boost/wiki/WikiStart#GitandModularBoost

Comments and corrections welcome!

I'm particularly interested in unanswered questions you have after reading these initial docs.

I haven't found answer to the following question(s):

What is the role, if any, of Ryppl and CMake in the Boost modularisation plan?

The answer is none. Modularization + the move to git is a big enough change to be done separately and to stand on its own merits. -- Eric Niebler BoostPro Computing http://www.boostpro.com

On Fri, Dec 7, 2012 at 1:29 PM, Oliver Kowalke <oliver.kowalke@gmail.com> wrote:

2012/12/7 Eric Niebler <eric@boostpro.com>

...

...

What is the role, if any, of Ryppl and CMake in the Boost modularisation plan?

The answer is none. Modularization + the move to git is a big enough change to be done separately and to stand on its own merits.

modularized boost will use in the first step boost.build/bjam in the first step and later the transition to cmake?

Modular Boost + Git has enough advantages that it is worth doing regardless of what happens in the future. But the intent is to continue work on further infrastructure improvements, for sure. The specifics will evolve over time, but cmake interest continues to be strong. --Beman

on Sun Dec 09 2012, Jookia <166291-AT-gmail.com> wrote:

On 09/12/12 01:04, Beman Dawes wrote:

...

On Fri, Dec 7, 2012 at 1:29 PM, Oliver Kowalke <oliver.kowalke@gmail.com> wrote: Modular Boost + Git has enough advantages that it is worth doing regardless of what happens in the future. But the intent is to continue work on further infrastructure improvements, for sure. The specifics will evolve over time, but cmake interest continues to be strong.

--Beman

Is there a current discussion on moving to CMake?

Not much discussion, but...

Or a status?

...Work in progress. You can experiment with the CMake port today (https://github.com/ryppl/boost-zero). Some tests still need to be ported to CMake. To automatically fetch dependencies, you'll want ryppl, which needs some work but is mostly functional. -- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost

Hi, This question is answered by another question: https://svn.boost.org/trac/boost/wiki/Git/WhyGit#WhyshouldBoostchooseGitasou... It looks like there is a missing...answer. Or is there no answer? I think there are at least arguments that have been discussed here before. Joel Lamotte

On Fri, Dec 7, 2012 at 2:22 PM, Klaim - Joël Lamotte <mjklaim@gmail.com> wrote:

Hi,

This question is answered by another question: https://svn.boost.org/trac/boost/wiki/Git/WhyGit#WhyshouldBoostchooseGitasou... It looks like there is a missing...answer. Or is there no answer? I think there are at least arguments that have been discussed here before.

Ah! Nice catch! I've added two reasons: Network effect (with a link to the wikipedia "network effect" article), and as Eric suggests, the folks doing the work prefer Git.) Thanks, --Beman

On 8 December 2012 13:53, Beman Dawes <bdawes@acm.org> wrote:

On Fri, Dec 7, 2012 at 12:28 PM, Mateusz Loskot <mateusz@loskot.net> wrote:

...

On 7 December 2012 16:54, Beman Dawes <bdawes@acm.org> wrote:

...

We are starting to pull together documentation for the Git and Modular Boost conversion.

https://svn.boost.org/trac/boost/wiki/WikiStart#GitandModularBoost

Comments and corrections welcome!

I'm particularly interested in unanswered questions you have after reading these initial docs.

I haven't found answer to the following question(s):

What is the role, if any, of Ryppl and CMake in the Boost modularisation plan?

Congratulations! You have the honor of submitting the first FAQ question. Eric's response has become the supplied answer.

Beman, You read my mind. Believe or not, I was going to start FAQ on the Wiki and add this as first Q&A. Thanks for heads up! Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

(Rearranging. Rene, I don't suppose you could bottom-post, could you?) On 12/7/2012 10:40 AM, René Rivera wrote:

On Dec 7, 2012, at 10:54 AM, Beman Dawes <bdawes@acm.org> wrote:

...

We are starting to pull together documentation for the Git and Modular Boost conversion.

https://svn.boost.org/trac/boost/wiki/WikiStart#GitandModularBoost

Comments and corrections welcome!

I'm particularly interested in unanswered questions you have after reading these initial docs.

There's no mention of supporting external developers/users that have subversion external links to the Boost subversion repo. How will people that have their internal development stored in subversion with references to Boost be supported? Will they be left out in the cold once svn.boost.org goes dark? Or will their be an equivalent subversion read only bridge they could use (after adjusting their references)?

Once the switch is made, subversion will be made read-only. It won't go away, but development will take place in the modularized git repos. Changes from git won't be pushed back into svn; that would become increasingly difficult as the structure of the repos diverge. Anybody who makes use of svn externals to track boost development will need to update to git. Is this scenario common enough that we should have a documented migration path for such people? -- Eric Niebler BoostPro Computing http://www.boostpro.com

On Fri, Dec 7, 2012 at 2:46 PM, Rene Rivera <grafikrobot@gmail.com> wrote:

On Fri, Dec 7, 2012 at 1:25 PM, Eric Niebler <eric@boostpro.com> wrote:

...

(Rearranging. Rene, I don't suppose you could bottom-post, could you?)

On 12/7/2012 10:40 AM, René Rivera wrote:

...

There's no mention of supporting external developers/users that have subversion external links to the Boost subversion repo. How will people that have their internal development stored in subversion with references to Boost be supported? Will they be left out in the cold once svn.boost.org goes dark? Or will their be an equivalent subversion read only bridge they could use (after adjusting their references)?

Once the switch is made, subversion will be made read-only. It won't go away, but development will take place in the modularized git repos. Changes from git won't be pushed back into svn; that would become increasingly difficult as the structure of the repos diverge. Anybody who makes use of svn externals to track boost development will need to update to git.

Is this scenario common enough that we should have a documented migration path for such people?

Since I'm one of the persons under that scenario my biased opinion is that yes it's common enough. But obviously I don't know how widespread the scenario is.

I've since moved on to another company, but at my last job at least three projects I worked on had a similar setup. They wouldn't be affected though since the externals were set up to the /releases/ directory and grabbed a certain tag (e.g. boost 1.41.0). I think this is probably the most common externals scenario. It seems the only people immediately affected would be those with svn:externals to boost/trunk, which seems like an unlikely scenario. Those with existing externals wishing to upgrade to the latest boost release would need that migration path, however. --Mike

On Fri, Dec 7, 2012 at 2:25 PM, Eric Niebler <eric@boostpro.com> wrote:

(cc'ing boost-steering ...)

...

On Fri, Dec 7, 2012 at 2:46 PM, Rene Rivera <grafikrobot@gmail.com> wrote:

...

On Fri, Dec 7, 2012 at 1:25 PM, Eric Niebler <eric@boostpro.com> wrote:

...

Once the switch is made, subversion will be made read-only. It won't go away, but development will take place in the modularized git repos. Changes from git won't be pushed back into svn; that would become increasingly difficult as the structure of the repos diverge. Anybody who makes use of svn externals to track boost development will need to update to git.

Is this scenario common enough that we should have a documented migration path for such people?

Since I'm one of the persons under that scenario my biased opinion is

On 12/7/2012 12:09 PM, Michael Fawcett wrote: that

...

...

yes it's common enough. But obviously I don't know how widespread the scenario is.

I've since moved on to another company, but at my last job at least three projects I worked on had a similar setup. They wouldn't be affected though since the externals were set up to the /releases/ directory and grabbed a certain tag (e.g. boost 1.41.0). I think this is probably the most common externals scenario.

It seems the only people immediately affected would be those with svn:externals to boost/trunk, which seems like an unlikely scenario.

That seems unlikely to me also. Rene?

I'm in that scenario for a bunch of my projects.. More specifically.. I track BBv2 from trunk as I use it as my build system. There might be others who track trunk versions of other individual libraries and tools. Don't really know though.

...

Those with existing externals wishing to upgrade to the latest boost release would need that migration path, however.

This could be accommodated easily, I think, but it's something we'd have to add. There will be a script used by the release managers to reassemble a monolithic boost from the modules for a release. All that would be needed would be to run that script nightly and push the results into a separate git repo for people to track. Naturally, that repo should be read-only for everybody except the bot executing the script.

Since, IMO, one is more likely to track trunk or release versions of individual parts of Boost.. Would it be helpful to have that same support be optionally provided? -- -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

On 12/7/2012 3:48 PM, Dave Abrahams wrote:

on Fri Dec 07 2012, Eric Niebler <eric-AT-boostpro.com> wrote:

...

(cc'ing boost-steering ...)

On 12/7/2012 12:09 PM, Michael Fawcett wrote:

...

I've since moved on to another company, but at my last job at least three projects I worked on had a similar setup. They wouldn't be affected though since the externals were set up to the /releases/ directory and grabbed a certain tag (e.g. boost 1.41.0). I think this is probably the most common externals scenario.

It seems the only people immediately affected would be those with svn:externals to boost/trunk, which seems like an unlikely scenario.

That seems unlikely to me also. Rene?

Me too, and I don't think we shoudl try to provide a seamless transition for every possible use case.

...

...

Those with existing externals wishing to upgrade to the latest boost release would need that migration path, however.

Those people would either stop using SVN externals for Boost, and simply check a copy of Boost into their source tree, or maintain their own SVN mirror of the boost releases (at least the ones they're interested in) and then point their externals to that mirror.

...

This could be accommodated easily, I think, but it's something we'd have to add. There will be a script used by the release managers to reassemble a monolithic boost from the modules for a release. All that would be needed would be to run that script nightly and push the results into a separate git repo for people to track.

I think that's a bad idea, because it would leave us responsible for maintaining a correspondence between said git repo and our other reality that meets peoples' expectations. Furthermore, I don't see how providing a Git repo is going to be much help to people that are using SVN externals.

Boost is making this transition. It *will* cause some disruption. It will also make things easier for some people. IMO we should not burden this move, which is supposed to make it easier and more efficient overall for Boost to operate, with any unnecessary obligations.

Well.. I found the more reasonable (in the sense that it doesn't leave people hanging that do what I do).. In the form of GitHub's subversion support <https://github.com/blog/1178-collaborating-on-github-with-subversion>. I tried this with the current BBv2 git project and it works nicely. So I would suggest that this is something we should add to the documentation. -- -- 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 Sat, Dec 15, 2012 at 7:56 PM, Dave Abrahams <dave@boostpro.com> wrote:

on Fri Dec 07 2012, Rene Rivera <grafikrobot-AT-gmail.com> wrote:

...

On 12/7/2012 3:48 PM, Dave Abrahams wrote:

...

Boost is making this transition. It *will* cause some disruption. It will also make things easier for some people. IMO we should not burden this move, which is supposed to make it easier and more efficient overall for Boost to operate, with any unnecessary obligations.

Well.. I found the more reasonable (in the sense that it doesn't leave people hanging that do what I do).. In the form of GitHub's subversion support <https://github.com/blog/1178-collaborating-on-github-with-subversion>. I tried this with the current BBv2 git project and it works nicely. So I would suggest that this is something we should add to the documentation.

If it really works, I'm all for documenting it. However, I'd be shocked if your existing externals will continue to work because a) we're not going to have a monolithic git repo and b) even in the repo with submodules (which will only track releases) it's going to have a different directory structure.

I'm not expecting it to work with my existing externals at all. All I want is a path for the developers that want to use and track in-development versions of libraries and tools and are using subversion (and can't change that use). The bridge does seem to work very well for read access. Within the limits of what such a bridge can offer that is. And at least for my use case, that is tracking and testing bbv2, it would work. Note, the only problem so far I've run into with the svn<=>github bridge is in using the advanced svn 1.7 commit model. But since it's read only that I'm really interested in. Although it might be that bbv2 development stays in subversion anyway, with occasional pushes to git. And for any libraries I deal with I'll likely use mercurial instead anyway. But I guess this is the price of switching to git.. More fragmentation and inconsistency in revision tools used in the Boost community. -- -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

On Sat, Dec 15, 2012 at 7:51 PM, Dave Abrahams <dave@boostpro.com> wrote:

on Fri Dec 07 2012, René Rivera <grafikrobot-AT-gmail.com> wrote:

...

There's no mention of supporting external developers/users that have subversion external links to the Boost subversion repo. How will people that have their internal development stored in subversion with references to Boost be supported? Will they be left out in the cold once svn.boost.org goes dark?

svn.boost.org doesn't go dark, I think. It does, however, stop getting updated.

Which is practically equivalent since it wouldn't get updated with releases. Personally I would schedule it to go offline at some point (perhaps in 2014) so that we don't have to worry about the maintenance of that resource.

...

Or will their be an equivalent subversion read only bridge they could use (after adjusting their references)?

No, that would be unreasonable, IMO.

I pointed out how there's already a zero effort working bridge.. So I'm curious why is it unreasonable? -- -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

On Sat, Dec 15, 2012 at 8:51 PM, Dave Abrahams <dave@boostpro.com> wrote:

on Fri Dec 07 2012, René Rivera <grafikrobot-AT-gmail.com> wrote:

...

There's no mention of supporting external developers/users that have subversion external links to the Boost subversion repo. How will people that have their internal development stored in subversion with references to Boost be supported? Will they be left out in the cold once svn.boost.org goes dark?

svn.boost.org doesn't go dark, I think. It does, however, stop getting updated.

Hopefully, this can be enforced by making svn.boost.org read only. --Beman

On 12/7/2012 11:44 AM, Oliver Kowalke wrote:

2012/12/7 Beman Dawes <bdawes@acm.org>

...

We are starting to pull together documentation for the Git and Modular Boost conversion.

https://svn.boost.org/trac/boost/wiki/WikiStart#GitandModularBoost

Comments and corrections welcome!

I'm particularly interested in unanswered questions you have after reading these initial docs.

I tried to compile/execute some unit-tests. Unfortunately some files seam to be missing (bootstrap.jam):

Unable to load Boost.Build: could not find build system. --------------------------------------------------------- /boost/boost-build.jam attempted to load the build system by invoking

'boost-build tools/build/v2 ;'

but we were unable to find "bootstrap.jam" in the specified directory or in BOOST_BUILD_PATH (searching /boost/tools/build/v2, /usr/share/boost-build).

I did: - git clone https://github.com/boost-lib/boost.git - cd boost/libs - git clone https://github.com/boost-lib/core.git - cd core/test - b2

Do I have to clone an additional submodule (which is not mentioned in the docu)?

Beman's docs appear to lack instructions for how to clone the super-project and initialize the sub-modules. That would be a nice addition. I don't know the steps and can't find them ATM, but I know it's documented *somewhere*. Beman? -- Eric Niebler BoostPro Computing http://www.boostpro.com

On 08.12.2012 20:03, Beman Dawes wrote:

On Fri, Dec 7, 2012 at 3:42 PM, Eric Niebler <eric@boostpro.com> wrote:

...

On 12/7/2012 11:44 AM, Oliver Kowalke wrote:

...

...

Do I have to clone an additional submodule (which is not mentioned in the docu)?

Beman's docs appear to lack instructions for how to clone the super-project and initialize the sub-modules. That would be a nice addition. I don't know the steps and can't find them ATM, but I know it's documented *somewhere*. Beman?

Just added: https://svn.boost.org/trac/boost/wiki/TryModBoost

The original instructions were buried in a C++Now presentation slide.

Uhm, so why is CMake now a requirement, and what are the plans for lifting said requirement? I realize that requiring CMake is ingenious plan to further say 'look, we require CMake already', but that sounds like a dubious approach. - Volodya

2012/12/11 Vladimir Prus <ghost@cs.msu.su>

On 08.12.2012 20:03, Beman Dawes wrote:

...

On Fri, Dec 7, 2012 at 3:42 PM, Eric Niebler <eric@boostpro.com> wrote:

...

On 12/7/2012 11:44 AM, Oliver Kowalke wrote:

Do I have to clone an additional submodule (which is not mentioned in the

...

...

docu)?

Beman's docs appear to lack instructions for how to clone the super-project and initialize the sub-modules. That would be a nice addition. I don't know the steps and can't find them ATM, but I know it's documented *somewhere*. Beman?

Just added: https://svn.boost.org/trac/**boost/wiki/TryModBoost<https://svn.boost.org/trac/boost/wiki/TryModBoost>

The original instructions were buried in a C++Now presentation slide.

Uhm, so why is CMake now a requirement, and what are the plans for lifting said requirement?

I wrote the script in CMake, because that way it was easiest for me. If someone implements the same functionality in Python, we can replace the script. I realize that requiring CMake is ingenious plan to further say 'look, we

require CMake already', but that sounds like a dubious approach.

Never attribute to malice...

On 11.12.2012 17:13, Jürgen Hunold wrote:> Hi,

On Tuesday, 11. December 2012 13:33:41 Daniel Pfeifer wrote:

...

2012/12/11 Vladimir Prus <ghost@cs.msu.su>

...

...

Uhm, so why is CMake now a requirement, and what are the plans for lifting said requirement?

I wrote the script in CMake, because that way it was easiest for me. If someone implements the same functionality in Python, we can replace the script.

Steven Watanabe has already mailed a patch to this standalon in the existing Boost.Build system. I just can't find the mail at the moment and the patch does not apply any more. Maybe Volodya can take a look at it?

FWIW, I am OK with requiring Python for building Boost. In particular, because I will be able to say 'look, we require Python already' when discussing Boost.Build/Python in future. But I'd be happy to help with pure Boost.Build solution as well - but I can't find email either. - Volodya

On 12 December 2012 06:43, Vladimir Prus <ghost@cs.msu.su> wrote:

But I'd be happy to help with pure Boost.Build solution as well - but I can't find email either.

I think it's this: http://lists.boost.org/Archives/boost/2012/05/193106.php But it looks like it's missing some development: http://lists.boost.org/Archives/boost/2012/05/193205.php

Paul A. Bristow wrote:

...

https://svn.boost.org/trac/boost/wiki/TryModBoost

I've tried to carry out these instructions but changing the names and files a tiny bit (Windows 7)

but I've stumbled at the test run stage with

thrice_test.cpp thrice_test.cpp(1) : fatal error C1083: Cannot open include file: 'boost/trivial/twice.hpp': No such file or directory

but it is here

I:\boost-trunk\libs\trivial\include\boost\trivial\thrice.hpp

I *think* I've got the directory structure right, and I created a symbolic link that looks promising:

I:\boost-trunk\boost>mklink /d trivial ..\libs\trivial\include\boost\trivial symbolic link created for trivial <<===>> ..\libs\trivial\include\boost\trivial

dir \trivial

doesn't find anything.

While I do some homework on symbolic links, any suggestions on where I have blundered?

I'd like to help you but I need to ask some questions first for clarification: - By "dir \trivial doesn't find anything", do you mean that Windows throws an error at you and/or you don't get to see any directory contents? If yes, does it help to leave out the backward slash (assuming you run the command while in I:\boost-trunk\boost)? - I think the symbolic link looks promising too, and I can't help but wonder whether the thrice_test.cpp error is actually still occurring since you made the link. I realise that you probably tried, just asking for maximum clarity. :-) - Are you experiencing these problems with existing Boost libraries as well? For example, Boost.Array? -Julian

Paul A. Bristow wrote:

...

From boost-trunk/boost (not /libs)

I:\boost-trunk\boost>dir array Volume in drive I is Boost Volume Serial Number is 2772-A18A

Directory of I:\boost-trunk\boost

File Not Found

I:\boost-trunk\boost>dir trivial Volume in drive I is Boost Volume Serial Number is 2772-A18A

Directory of I:\boost-trunk\boost\trivial

14-Dec-2012 14:29 <DIR> . 14-Dec-2012 14:29 <DIR> .. 14-Dec-2012 14:29 210 thrice.hpp 1 File(s) 210 bytes 2 Dir(s) 55,078,617,088 bytes free

So this proves that you *do* have a symlink to the trivial headers in boost-trunk\boost, but *not* to the array headers. From this we can infer that - Daniel was right to point out that you didn't run the header forwarding command from the TryModBoost instructions; - your problem in compiling thrice_test.cpp is not caused by a lack of symlinks. (I'll reply to the other two late emails shortly.)

-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Daniel Pfeifer Sent: Friday, December 14, 2012 5:05 PM To: boost@lists.boost.org Subject: Re: [boost] [Git] Documentation for Git and Modular Boost conversion

2012/12/14 Paul A. Bristow <pbristow@hetp.u-net.com>

...

...

-----Original Message----- From: boost-bounces@lists.boost.org [mailto: boost-bounces@lists.boost.org] On Behalf Of Beman Dawes Sent: Saturday, December 08, 2012 4:03 PM To: boost@lists.boost.org Subject: Re: [boost] [Git] Documentation for Git and Modular Boost conversion

On Fri, Dec 7, 2012 at 3:42 PM, Eric Niebler <eric@boostpro.com> wrote:

...

On 12/7/2012 11:44 AM, Oliver Kowalke wrote:

...

...

Do I have to clone an additional submodule (which is not mentioned in the docu)?

Beman's docs appear to lack instructions for how to clone the super-project and initialize the sub-modules. That would be a nice addition. I don't know the steps and can't find them ATM, but I know it's documented *somewhere*. Beman?

Just added: https://svn.boost.org/trac/boost/wiki/TryModBoost

I've tried to carry out these instructions but changing the names and files a tiny bit (Windows 7)

but I've stumbled at the test run stage with

thrice_test.cpp thrice_test.cpp(1) : fatal error C1083: Cannot open include file: 'boost/trivial/twice.hpp': No such file or directory

but it is here

I:\boost-trunk\libs\trivial\include\boost\trivial\thrice.hpp

thrice != twice! Is that a typo in your email or in your code?

No I wanted to change the name of the library and its code. Does "boobooboo" ;-)

...

I *think* I've got the directory structure right, and I created a symbolic link that looks promising:

I:\boost-trunk\boost>mklink /d trivial ..\libs\trivial\include\boost\trivial

So you tried to create the symlinks manually...

https://svn.boost.org/trac/boost/wiki/StartModDev says "Create a symlink to simulate your library being installed as part of Boost: Windows: mklink /d simple ..\libs\simple\include\boost\simple POSIX: ln -s ../libs/simple/include/boost/simple simple"

If you followed the documentation, you should have called this instead:

cmake -P forward_headers.cmake

Huh? I'm not using cmake am I? I'm using bjam/b2 aren't I? But thanks Paul

Daniel Pfeifer wrote:

...

thrice_test.cpp thrice_test.cpp(1) : fatal error C1083: Cannot open include file: 'boost/trivial/twice.hpp': No such file or directory

but it is here

I:\boost-trunk\libs\trivial\include\boost\trivial\thrice.hpp

thrice != twice! Is that a typo in your email or in your code?

Well spotted, Daniel. I'm almost sure this must be the solution. Paul, does your thrice_test.cpp contain a line of the following form? #include <boost/trivial/twice.hpp> If so, does the problem go away if you replace it by this? #include <boost/trivial/thrice.hpp> (one more email to go)

On Sat, Dec 15, 2012 at 9:10 PM, Dave Abrahams <dave@boostpro.com> wrote:

on Sat Dec 08 2012, Andrey Semashev <andrey.semashev-AT-gmail.com> wrote:

...

Maybe I missed it somewhere but do I understand correctly that develop branch corresponds to the current trunk? Also, what branches will be tested?

I would also like to see instructions of checking out and composing a monolithic Boost distribution, possibly with (or without) only selected libraries.

Short answer:

git clone --recursive https://github.com/boost-lib/boost.git

gets everything. If you start with a non-recursive clone then you can control which submodules you get; see the Git documentation (yes, a more complete answer should go on the wiki).

...

As I understand, the common boost/ directory with links to library headers would have to be recreated somehow.

cd boost cmake -P forward_headers.cmake

At the time Andrey asked the question, that hadn't been documented yet. It is now covered by: https://svn.boost.org/trac/boost/wiki/TryModBoost

...

And is there a way to specify dependencies between libraries?

Some of that is already present in the Jamfiles.

...

Is it possible to checkout lib A and everything it requires?

Added to https://svn.boost.org/trac/boost/wiki/ModCvtFAQ --Beman

On Sat, Dec 8, 2012 at 5:20 PM, Rene Rivera <grafikrobot@gmail.com> wrote:

Are the "non-boost" svn sources kept in git? I.e. where's the sandbox content? Where's the web site content? etc.

Excellent questions! Thanks! AFAIK, Git will become the official VCS for all of Boost. Thus any content that is still active should be moved to a git repo, But I can't recall any specific discussions, so what follows is just a guess. The whole need for the sandbox being part of a boost repo goes away. A proposed library such as used to go in the sandbox now just goes in its own public repo. Probably easiest if it is hosed on GitHub, but it could be hosted anywhere. I'll update https://svn.boost.org/trac/boost/wiki/StartModDev to more clearly show how that works. For existing sandbox libraries that the owner wants to migrate to a Git public repo, possibly retaining history, we will want to provide whatever support is needed. I haven't given any thought to migrating the web site. Dave? --Beman

On Sat, Dec 15, 2012 at 8:22 PM, Dave Abrahams <dave@boostpro.com> wrote:

on Mon Dec 10 2012, Beman Dawes <bdawes-AT-acm.org> wrote:

...

For existing sandbox libraries that the owner wants to migrate to a Git public repo, possibly retaining history, we will want to provide whatever support is needed.

I haven't given any thought to migrating the web site. Dave?

I think a regular git-svn migration will mostly work, but I am not entirely clear on what's needed in order to reference the html in individual libraries' doc/ subdirectories. Rene?

Well.. Moving with git-svn is only about 5% of the work on that. A few things to deal with: * The current management, i.e. editing, of the website is possible because of a post-commit hook that updates the web site content as it changes in the svn repo. So that would have to be replicated in some form as manually updating content is unmaintainable. Note, per Beman's request I already pushed the scripts doing this onto svn. * The current library documentation relies on having the previous Boost releases around on disk (the monolithic releases). Hence if we are going to keep having monolithic releases all we need is to have an established, i.e. automated, release archive process that we can grab and expand archives for beta preview use. If we aren't going to have monolithic releases then we will have to write some code to deal with both styles of releases. * In all of this we have to deal with the fact that the "active" state of web site editing will not reside in the web server itself. Which will make for somewhat more cumbersome management. It will also increase the chances of tampering with the web site as there are more points of security failure involved. * We do also have the option of not migrating the web site source repo. As once the rest of the svn traffic goes way from the current server the load will improve dramatically. And the rationale for switching the web site source to a DVCS is rather specious at best. -- -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

On Sat, Dec 8, 2012 at 8:43 PM, Julian Gonggrijp <j.gonggrijp@gmail.com> wrote:

Browsing through the wiki pages linked from that section, a few things caught my attention.

wiki/ModCvtSvn2Git [1] states

...

Each individual Boost library's public repository will contain a single branch, "master", that corresponds to branches/release in Subversion.

As I seemed to recall that the modularized Boost would adopt GitFlow,

Yes, that's the plan.

I was surprised by the suggestion that a library's public repository would not be allowed (or at least not required) to have a "develop" branch corresponding to the Subversion "trunk".

Hum... That's too narrow an interpretation. I've added wording to distinguish between initial state at conversion and then the ongoing workwflow

Indeed when I opened wiki/StartModWorkflow [2] it turned out that the wiki pages don't internally agree on this issue yet:

...

An unusually simple, single developer library would have only the permanent *develop* and *master* branches that are required for all Boost libraries.

Furthermore the bullet list at the top of [1] seems to suggest that the new Git repositories will not keep track of any history; only the list item dedicated to the old Svn repo mentions "full history". I believe this to be partly due to an inaccuracy, because the individual library repos will contain /branches/ which supposedly will hold all commits made to those brances. This is also further explained in [2].

Another reason might be (IIUC) that after the initial conversion, the individual library repos will start with only a clean copy of the latest state on the Svn repo. Nonetheless I believe the current wording on the wiki page can be needlessly alarming to the less gitflow-enlightened reader, because it may seem to suggest that it still won't record history /after/ the initial conversion.

Wording clarified.

While wiki/ModCvtSchedule [3] may be alpha, the schedule seems ambitious enough that I think it would be wise to get all library maintainers ready for take-off as soon as possible. Even if you don't really plan to have library maintainers start beta testing the Git repos next week as the schedule suggests, I think about *now* is the time to make a global announcement on this mailing list that developers will need to install Git and familiarise themselves with it sometime soon. I believe an exact date is not needed to license such an announcement.

Yes, but the feeling was that documentation had to be provided before making such an announcement. That's why the docs are being developed this week.

For wiki/Git/GitHome [4] I would like to suggest two additions: - Add git-flow [5] to the "Installing Git" list. - Add GitImmersion [6] to the "Learning to use Git" list.

That's the second recommendation I've seen for Gitimmersion, so I've added it even though I haven't a chance to review it myself. I also added a reference to the workflow page for those interested in git-flow.

Hope this helps!

Yes, for sure! Thanks, --Beman

On Mon, Dec 10, 2012 at 2:07 PM, Julian Gonggrijp <j.gonggrijp@gmail.com> wrote:

Beman Dawes wrote:

...

Yes, but the feeling was that documentation had to be provided before making such an announcement. That's why the docs are being developed this week.

Ah, of course. Excuse me.

...

I also added a reference to the workflow page for those interested in git-flow.

If I understand correctly you put it over there and not on the resources page because it's a command line tool which not everyone is interested in. On the other hand: not everyone is interested in a Windows GUI tool like TortoiseGit either. Why not just put the git- flow tool on the resources page as well? It will be quite helpful for those using the command line, given that GitFlow is adopted by Boost.

I'm deferring workflow discussion, and thus GitFlow, to a separate page to avoid piling on too many new ideas for developers who have never used Git before. Also, "the best is the enemy of the good" applies to this doc effort. We need to get "good enough" docs up for developers now, rather than superb docs up later:-) Thanks, --Beman

on Mon Dec 10 2012, Beman Dawes <bdawes-AT-acm.org> wrote:

On Sat, Dec 8, 2012 at 8:43 PM, Julian Gonggrijp <j.gonggrijp@gmail.com> wrote:

...

Browsing through the wiki pages linked from that section, a few things caught my attention.

wiki/ModCvtSvn2Git [1] states

...

Each individual Boost library's public repository will contain a single branch, "master", that corresponds to branches/release in Subversion.

As I seemed to recall that the modularized Boost would adopt GitFlow,

Yes, that's the plan.

...

I was surprised by the suggestion that a library's public repository would not be allowed (or at least not required) to have a "develop" branch corresponding to the Subversion "trunk".

Hum... That's too narrow an interpretation. I've added wording to distinguish between initial state at conversion and then the ongoing workwflow

I'm sorry, but I have always intended to do what Julian thought: produce an initial "develop" branch corresponding to "trunk" along with "master." -- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost

Beman Dawes wrote:

On Sat, Dec 15, 2012 at 9:42 PM, Dave Abrahams <dave@boostpro.com> wrote:

...

I'm sorry, but I have always intended to do what Julian thought: produce an initial "develop" branch corresponding to "trunk" along with "master."

No problem. Daniel P has committed to updating the conversion script so that will happen, and I've just now updated docs accordingly.

I wonder how testing will work. Will the "develop" and "master" branches of each repo be tested?

on Sun Dec 16 2012, "Peter Dimov" <lists-AT-pdimov.com> wrote:

Beman Dawes wrote:

...

On Sat, Dec 15, 2012 at 9:42 PM, Dave Abrahams <dave@boostpro.com> wrote:

...

I'm sorry, but I have always intended to do what Julian thought: produce an initial "develop" branch corresponding to "trunk" along with "master."

No problem. Daniel P has committed to updating the conversion script so that will happen, and I've just now updated docs accordingly.

I wonder how testing will work. Will the "develop" and "master" branches of each repo be tested?

What's going to be tested is fluid. The ultimate goal is to allow developers to request specific combinations of tests with each commit by modifying a .json file in their project's root directory. In the meantime, I expect to test every commit on any branch. The biggest question is against which versions of Boost dependencies the commit will be tested. The obvious choices are 1. the version that was part of the last boost release, and 2. the last version of the dependency to be individually released (i.e. that dependency's "master" branch). Feedback/opinions on that choice are most welcome. -- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost

on Mon Dec 17 2012, Rene Rivera <grafikrobot-AT-gmail.com> wrote:

On Mon, Dec 17, 2012 at 11:36 AM, Dave Abrahams <dave@boostpro.com> wrote:

...

on Sun Dec 16 2012, "Peter Dimov" <lists-AT-pdimov.com> wrote:

...

...

On Sat, Dec 15, 2012 at 9:42 PM, Dave Abrahams <dave@boostpro.com> wrote:

...

I'm sorry, but I have always intended to do what Julian thought:

Beman Dawes wrote: produce

...

...

an initial "develop" branch corresponding to "trunk" along with "master."

No problem. Daniel P has committed to updating the conversion script so that will happen, and I've just now updated docs accordingly.

I wonder how testing will work. Will the "develop" and "master" branches of each repo be tested?

What's going to be tested is fluid. The ultimate goal is to allow developers to request specific combinations of tests with each commit by modifying a .json file in their project's root directory. In the meantime, I expect to test every commit on any branch.

The biggest question is against which versions of Boost dependencies the commit will be tested. The obvious choices are 1. the version that was part of the last boost release, and 2. the last version of the dependency to be individually released (i.e. that dependency's "master" branch).

Feedback/opinions on that choice are most welcome.

Since there are clearly some decisions outside of my understanding as testing manager, and part of the release team... Could someone please comment on what is expected for the release that is based from github?

Sorry, the question is too vague for me to answer. What kind of expectations, expected by whom, and for the release of what (I presume Boost as a whole, but pls confirm)?

Because barring any other direction testing will be exactly what it is right now.. Which is to test the the *release* (either trunk/develop of release/master branches) structure of Boost.

For monolithic Boost testing, boost's master repo (the one containing the submodules) will have some number of active branches. We can decide which of those branches get tested. Each such branch specifies the precise versions of all component libraries that will be tested. -- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost

on Mon Dec 17 2012, Julian Gonggrijp <j.gonggrijp-AT-gmail.com> wrote:

Dave Abrahams wrote:

...

on Sun Dec 16 2012, "Peter Dimov" wrote:

...

I wonder how testing will work. Will the "develop" and "master" branches of each repo be tested?

What's going to be tested is fluid. The ultimate goal is to allow developers to request specific combinations of tests with each commit by modifying a .json file in their project's root directory. In the meantime, I expect to test every commit on any branch.

Wouldn't the latter be a giant amount of work for the testers?

No, it will happen automatically. Testers aren't going to have to intercede.

I do subscribe to the idea that testing should be configurable by the developers. I'm not sure whether a file that is subject to version control would be a wise way to provide for that configurability.

We've thought it through for years and IMO it's an extremely attractive option. Having a record of exactly what was tested alongside the commit seems like a good idea to me. What is your objection?

Not all testing should be optional, I think;

Of course not.

form my understanding of the purpose of the test infrastructure it seems that the temporary release branches (gitflow style) should always be tested.

Sure.

...

The biggest question is against which versions of Boost dependencies the commit will be tested. The obvious choices are 1. the version that was part of the last boost release, and 2. the last version of the dependency to be individually released (i.e. that dependency's "master" branch).

Feedback/opinions on that choice are most welcome.

Definitely option 2, conflicts are likely to be found sooner in that way.

The downside of that approach is that one library developer creating a broken individual release may break testing for all other libraries, causing general instability and upset. That is currently the case for many people with trunk testing today, and some of us have been arguing for a long while that it would be better to do most testing against the last stable release of a library. Presumably that effect would be somewhat mitigated by testing against only *releases* of individual library dependencies, but it would not be entirely eliminated. We can avoid this problem by allowing developers to decide which version of individual dependencies they want to test against. In general one might want to stick with the last released Boost version, but occasionally one might need features developed during the current Boost release cycle, in which case the .json file could specify a later revision. -- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost

Dave Abrahams wrote:

The biggest question is against which versions of Boost dependencies the commit will be tested. The obvious choices are 1. the version that was part of the last boost release, and 2. the last version of the dependency to be individually released (i.e. that dependency's "master" branch).

This is fine in some scenarios, not so fine in others. Imagine that the "develop" branch of, say, SmartPtr introduces a potentially breaking change, say, use of explicit operator bool. Until dependent libraries are tested against this change, it will not become known whether they are affected.

Peter Dimov wrote:

Dave Abrahams wrote:

...

The biggest question is against which versions of Boost dependencies the commit will be tested. The obvious choices are 1. the version that was part of the last boost release, and 2. the last version of the dependency to be individually released (i.e. that dependency's "master" branch).

This is fine in some scenarios, not so fine in others. Imagine that the "develop" branch of, say, SmartPtr introduces a potentially breaking change, say, use of explicit operator bool. Until dependent libraries are tested against this change, it will not become known whether they are affected.

This is effectively the same as using all the other libraries to test the one library with the change. There are a number of reasons I don't like this idea. a) It consumes a large number of resources - a change on in one library triggers tests on all other libraries which might depend upon it. b) When a change in library A provokes a failure in library B library B's author has to go on a bug hunt to eventually conclude that the error was caused in some place where he had no place to look. c) library B's tests are really designed to check pre-requisite library A. They just assume that library A works. If they can't assume that - then the tests for library B have to be a lot more complicated. Then it's even harder to find the source of a failure. d) The real solution is to add more tests to library A. But that's hard now since our testing infrastructure is heavily loaded - in large part re-testing depending libraries. e) some libraries like boost test are used in the testing itself. These can't be "under construction" at the same time they are being used as part of the test infrastructure. I would like to re-iterate the idea that trunk and release libraries be tested against the next release (ie the current release branch). Robert Ramey PS - On personal machine, I have the release branch loaded and just switched to the trunk for the serialization library. This has made my life much easier since I've avoid the above problems. PPS - Hmmm - I wonder if this will be possible/easy under the Git system.

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

On Mon, Dec 17, 2012 at 6:14 PM, Dave Abrahams <dave@boostpro.com> wrote:

on Mon Dec 17 2012, "Robert Ramey" <ramey-AT-rrsd.com> wrote:

...

I would like to re-iterate the idea that trunk and release libraries be tested against the next release (ie the current release branch).

Problems with the way your idea is expressed:

0. I'm not sure you mean "release branch" as defined by gitflow, which defines our branching policy. You might want to take a look at that.

1. In the gitflow model, "release branches" are temporary. You need to decide what to test against when there's no release branch.

2. "The current release branch" is not specific enough. Each individual library *and* the Boost super-project can all have release branches, and they almost certain do not correspond to one another. The Boost super-project should release combinations of states on the "master" branches of individual libraries.

...

Robert Ramey

PS - On personal machine, I have the release branch loaded and just switched to the trunk for the serialization library. This has made my life much easier since I've avoid the above problems.

PPS - Hmmm - I wonder if this will be possible/easy under the Git system.

The model described in the PS is possible/easy. The idea quoted at the top is still not clear enough to say anything about.

I think perhaps Robert may be using current subversion branch naming, so in the GitFlow model what he is talking about testing against is "master". Until enough time passes to be reasonably sure everyone has switched to the GitFlow branch naming, every time someone refers to "release branch" without being more specific, we really have to ask them if they are talking about the old svn branches/release (i.e. they should have called it "master" if talking about modular Boost) or the GitFlow temporary (and often private) release staging branches that do not represent the latest actual release? --Beman

on Mon Dec 10 2012, Rene Rivera <grafikrobot-AT-gmail.com> wrote:

In browsing the repos <https://github.com/boost-lib> I notice that some changes/actions have real users attached to them. While others just have the "modbot" user. Is there a procedure for matching new users to old users?

Yes, there will be. However

Along the same line of questioning.. Is there a procedure for getting users added to the members of the "boost-lib" organization(user)?

Now you can make administrative requests at https://github.com/boost-lib/admin/issues Setting this up is a little clumsy, but what I did was to make a team called "admin" and a repo called "admin" under the boost-lib organization, and assigned the repo to the team. The team (right now, and totally subject to adjustment) is Daniel Pfeifer, Beman Dawes, Eric Niebler, and me. We're also on the special "owners" team for the boost-lib org. According to GitHub docs, the team will receive email for every issue opened on that tracker. -- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost

On Sat, Dec 15, 2012 at 10:31 PM, Rene Rivera <grafikrobot@gmail.com> wrote:

On Sat, Dec 15, 2012 at 8:39 PM, Dave Abrahams <dave@boostpro.com> wrote:

...

...

Now you can make administrative requests at https://github.com/boost-lib/admin/issues

Setting this up is a little clumsy, but what I did was to make a team called "admin" and a repo called "admin" under the boost-lib organization, and assigned the repo to the team. The team (right now, and totally subject to adjustment) is Daniel Pfeifer, Beman Dawes, Eric Niebler, and me. We're also on the special "owners" team for the boost-lib org. According to GitHub docs, the team will receive email for every issue opened on that tracker.

OK. But I guess after thinking about this more I'm more wondering what the security, permissions, responsibilities, library release flow, etc. will work?

Do developers get to own the boost sublib repos, and hence manage when and how their libraries make it into the releases?

Yes, subject to details. Also, a library can do a release whenever convenient, and it become available to users at that point, even though the next Boost release may be some time off. Users who care can employ the GitHub watch mechanism to know what is happening to a library. See https://help.github.com/articles/be-social

Or only the Boost admins, and the developers have to ask the admins to update from clones?

I'm not sure what the exact mechanism will be - Git gives us several choices and the release managers need to start to look at what way we want to do it.

Sorry if this is already documented somewhere, but I don't remember reading it when I first read Beman's new docs.

Some of it isn't documented because of time pressure, or because I'm not aware of details worked out by others, or because the details aren't worked out at all yet. Part of my rationale for "release early, release often" wrt docs was to flush out areas where we need to make decisions. I'm overwhelmed at the moment, but perhaps in a week or ten days we can get a new discussion started about how releases will work. In the meantime, reading about how Git sub-modules work might be useful prep. --Beman

On Sun, Dec 16, 2012 at 9:56 AM, Dave Abrahams <dave@boostpro.com> wrote:

on Sat Dec 15 2012, Rene Rivera <grafikrobot-AT-gmail.com> wrote:

...

On Sat, Dec 15, 2012 at 8:39 PM, Dave Abrahams <dave@boostpro.com> wrote:

If yes, will there be a period where we ask for developers to register

...

what their github account is for mapping?

It goes by email address, not github account. The mapping is partially complete and I am working on resolving all the unresolved names. Whether such a period will be needed eventually, I don't know.

Ah.. AFAIK it goes by identity corresponding to the github account. I.e. by email address of the account (which is why I said github account). There is a fine distinction as people can have an entirely different email attached to their github account that what they have in the current library maintenance records. Hence we will need people to verify that the emails we use for the mapping are correct. -- -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

On Sun, Dec 16, 2012 at 6:56 PM, Dave Abrahams <dave@boostpro.com> wrote:

on Sun Dec 16 2012, Rene Rivera <grafikrobot-AT-gmail.com> wrote:

...

On Sun, Dec 16, 2012 at 9:56 AM, Dave Abrahams <dave@boostpro.com> wrote:

...

on Sat Dec 15 2012, Rene Rivera <grafikrobot-AT-gmail.com> wrote:

There is a fine distinction as people can have an entirely different email attached to their github account that what they have in the current library maintenance records.

Yes, and they can attach multiple emails to their github account IIRC.

Ah. That I did not know. So developers just have to make sure the git email we use is on file, got it. -- -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

On 11/12/12 18:23, Daniel Pfeifer wrote:

The superproject has (nearly) the same directory layout as the current boost root. Short term, integration/release testing works very similar to the current process. Long term, we are working out a process that allows us to release subprojects separately.

Would this simplify stuff like the bcp tool?

On 11/12/12 19:30, Daniel Pfeifer wrote:

2012/12/11 Jookia <166291@gmail.com>

...

On 11/12/12 18:23, Daniel Pfeifer wrote:

...

The superproject has (nearly) the same directory layout as the current boost root. Short term, integration/release testing works very similar to the current process. Long term, we are working out a process that allows us to release subprojects separately.

Would this simplify stuff like the bcp tool?

It will rather obsolete the bcp tool.

That's even better, but wouldn't we still require dependency resolution?

On Tue, Dec 11, 2012 at 1:23 AM, Daniel Pfeifer <daniel@pfeifer-mail.de>wrote:

2012/12/10 Rene Rivera <grafikrobot@gmail.com>

...

Other than a schedule when integration/release testing is going to be set up.. I don't see how that is going to be set up.. How does integration/release testing work in, i must assume for now, the boost-lib/boost superproject?

The superproject has (nearly) the same directory layout as the current boost root. Short term, integration/release testing works very similar to the current process. Long term, we are working out a process that allows us to release subprojects separately.

Yes.. But let me rephrase the questions a bit.. As the testing manager (yes that's me even if I really don't have to do anything at this point since we haven't had real problems in ages now).. What is the procedure that testers will follow? Is there documentation equivalent to < http://www.boost.org/development/running_regression_tests.html> for the new setup? What changes to the current tools need to happen to the adjust to the new setup? -- -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

On Tue, Dec 11, 2012 at 9:29 AM, Paul A. Bristow <pbristow@hetp.u-net.com> wrote:

* GitHub.? exercise? and other links are broken?

Fixed all the broken links, including creation of https://svn.boost.org/trac/boost/wiki/StartGitHub

* Layout of directory structure seems a significantly different structure to most Boost libraries, with boost_1-0-99/boost and boost_1-0-99/libs (as referenced http://www.boost.org/development/requirements.html#Directory_structure. Is this intended?

* Where do example and doc (and build and src go)?

* Surely no library project (however simple) should exist without /doc and /example (and /test) folders?

I've added a comment explaining the omissions are for the sake of brevity.

* The output from any non-trivial library will be better sent to a log file - and even simple ones that don't work as expected are better attached to a "help!" message than pasted suffering end-of-line mutilation by the mail program.

Changed.

* "Hint: (((git help command-name}}}... " does look right? A TODO?

Fixed formatting typo.

* Has anyone actually used these instructions yet? (Some previous Boost instructions didn't actually work if you followed them blindly :-(

They work on my main desktop Windows machine. Has anyone else tried them?

* These instructions don't guide a user with an IDE Visual Studio, NetBeans, Eclipse ... on how to set up their project so that it can be easily transferred from (and to) the development tool.

Perhaps Boosters could contribute pages for various IDE's. I could do VisualStudio, but doubt I'll have time in the immediate future.

* Nor do they deal with the most common case of people moving sandbox SVN projects to git. Or will this be done automatically? (Some might be pruned as obsolete/abandoned?

There has been some discussion of that, but no one has committed to documenting the process. Any takers? Thanks for your careful reading, much appreciated! --Beman

On Tue, Dec 11, 2012 at 12:07 PM, Paul A. Bristow <pbristow@hetp.u-net.com> wrote:

...

-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Beman Dawes Sent: Tuesday, December 11, 2012 4:50 PM To: boost@lists.boost.org Subject: Re: [boost] [Git] Documentation for Git and Modular Boost conversion

On Tue, Dec 11, 2012 at 9:29 AM, Paul A. Bristow <pbristow@hetp.u-net.com> wrote:

...

* Layout of directory structure seems a significantly different structure to most Boost libraries, with boost_1-0-99/boost and boost_1-0-99/libs (as referenced http://www.boost.org/development/requirements.html#Directory_structure. Is this intended?

You haven't confirmed that the directory structure has changed significantly.

I've added some additional works to hopefully make it clearer that the location of header directories and headers has indeed moved.

Was boost-root/boost/simple/ simple.hpp ... /detail/stuff.hpp

boost-root/libs/simple/ test boost-root/libs/simple/example boost-root/libs/simple/doc

now is boost-root/libs/simple/include/simple.hpp ...

Actually, now is boost-root/libs/simple/include/boost/simple/simple.hpp Note that the install procedure will install a logical link from boost-root/boost/simple to boost-root/libs/simple/include/boost/simple so that user includes like #include <boost/simple/simple.hpp> still work. (Whether "logical link" is one link for the directory or one per header, and whether symlinks, hard links, or file copies are used is an implementation detail.)

and

boost-root/libs/simple/test, boost-root/libs/simple/example boost-root/libs/simple/doc ...

There was a logic (about whose details I am having a senior moment) for the previous structure.

A user wants to be able to tell a compiler "-Iboost-root" once, rather than have to supply a path for each library. At the time, we didn't want to bother with logical links.

I just want to be sure that the change is intended (and perhaps even understand why ;-)

(1) A unified directory structure for each library makes sense when libraries live in their own public repos. (2) We want to preserve existing user code, (3) we want to limit changes to directory structure as much as possible.

Would it be useful if I actually created a simple example - trying to follow your docs?

Yes! --Beman

2012/12/12 Robert Kawulak <robert.kawulak@gmail.com>

...

From: Beman Dawes now is boost-root/libs/simple/include/boost/simple/simple.hpp

Note that the install procedure will install a logical link from boost-root/boost/simple to boost-root/libs/simple/include/boost/simple so that user includes like #include <boost/simple/simple.hpp> still work.

Sorry if it has been written somewhere and I'm overlooking it, but what happens to convenience headers of the form "boost-root/boost/lib.hpp" that include everything from "boost-root/boost/lib/"? Do they simply go to "boost-root/libs/lib/include/boost/lib.hpp" and also get linked?

Yes.

Or are they unsupported and "boost-root/libs/lib/include/boost/lib/all.hpp" is the preferred convention instead?

No, we try to avoid breaking changes whenever possible.

Moreover - especially in the latter case - why the "boost/lib/" sub-dir in "include/"? Couldn't the hierarchy be simplified so that a library's include files go straight to "boost-root/libs/lib/include/"? Is it to allow for including a stand-alone library's files consistently by using "#include <boost/lib/...>"?

Correct. The reason again is modularization. In the future, if you want to use lib, you will download that lib (and its dependencies), add the 'include' directory of lib (and all its dependencies) to your compilers include path, and compile your source code. No changes will be needed in your source code. Resolving the dependencies of lib is something that you don't want to do manually. We plan to provide a tool that automatically resolves and downloads lib including its dependencies and also sets up your workspace with all include paths correctly set up. -Daniel