On 10/18/2013 01:17 AM, Eric Niebler wrote:

...

Assuming they can be broken by moving some files aroung (I believe they can be), we end up with a small graph of strongly connected components:

http://steveire.com/boost/graph_after_remaining.dot http://steveire.com/boost/graph_after_remaining.png

There are now 18 edges and 11 nodes. I was incredulous at first that proto depended in any way on Spirit. But

On 10/17/2013 3:24 PM, Stephen Kelly wrote: there are a few out-of-date and totally unused files in proto/detail that include non-existent spirit/fusion headers. I'll get this cleaned up, which will remove one more cyclic dependency. Thanks for doing this work.

Great, thanks for the cleanup and for the appreciation. Steve.

On 10/18/2013 03:06 AM, Niall Douglas wrote:

On 18 Oct 2013 at 0:24, Stephen Kelly wrote:

...

Obviously, this is not perfect, but it is a beginning, and it is mostly now a directed graph.

Any comments? This is really great work. My comment is to firstly thank you, and secondly is there a chance that this output could be generated automatically from trunk?

Nope. I'm generating it automatically from the modularized boost repos. The information about where files are moved to in the modularized repos does not exist in trunk. That information is in Boost2Git as described here: http://thread.gmane.org/gmane.comp.lib.boost.devel/241061 I think it's easy enough to generate from the modularized repos anyway. Thanks, and thanks for the appreciation, Steve.

Niall Douglas wrote:

I would *personally* prefer to see the moving around of files and associated fixups done in the SVN repo before moving to git, because unlike svn once git's history is written, it is forever unchangeable. Also, moving files between git submodules after the git move will lose history.

To be honest I think the history is not lost, it's just discontinuous. Especially if the commit in the source repo that deletes the file refers to the target repo and vice versa, you can still trace back what happened to a file all the way to its first creation. Of course, continuous history is still more convenient than discontinous history. I also think Steve is right that a post-switch context where people panic about git is not ideal for decoupling libraries -- although I don't have any strong intuitions of my own about how bad that panic will be. I can also relate to this:

But in the end, so long as the git output can compile, I don't care that strongly.

...

Thanks, and thanks for the appreciation,

What you're doing will always be underappreciated. I've done your job before on a mature codebase, and it was never ending political problems rather than technical problems. I feel for you, for sure.

Well spoken. -Julian

On 10/18/2013 03:14 AM, Philip Bennefall wrote:

Hi Stephen,

This looks excellent! Thank you for what seems to be a lot of really useful work thus far. If Boost becomes more modular and, above all, less interdependent, I'll certainly be using it more in my projects.

Thanks for the feedback. Yes, me too. For many of our clients boost is too big and non-modular to use currently. Thanks, Steve.

On 10/18/2013 04:08 AM, Emil Dotchevski wrote:

I'm worried that moving this header outside of the Exception library will lead to dependencies being injected at a later time.

I don't understand. Can you explain your worry? Thanks, Steve.

On 10/18/2013 06:01 AM, Edward Diener wrote:

On 10/17/2013 6:24 PM, Stephen Kelly wrote:

...

Hi there,

my plan for modularizing and modernizing Boost was roughly this:

* Phase 0 - remove dead weight by bumping compiler feature requirements * Phase 1 - move some files around so that the modularized repos form a mostly directed graph

I disagree with the idea that dependencies should be reduced unless there is a better reason than just analyzing a directed graph.

The reason to transform the cyclic mesh into a directed graph was never "just analysis". Primarily it is dependency (at the repo/package level, not the file level) reduction. http://thread.gmane.org/gmane.comp.programming.tools.ryppl.devel/201 That's the entire reason I arrived on the boost list.

Once you start moving code just to reduce dependencies you may actually end increasing dependencies for end-users. The typical situation showing this is:

Library AAA depends on Library BBB and nothing else in Boost currently depends on library BBB so you decide to move library BBB into library AAA to reduce a dependency. Now you have the end-user who uses library BBB in his code. After the move the end-user now depends on library AAA, but library AAA may is now bigger than before and if it is a library which must be built the end-user must ship a much larger shared library even though he may only need a small part of a library.

Even if library BBB is only a header only library why should the user of library BBB have to know about library AAA to use just the part of library BBB he used before ?

The current situation is that to use any one of 68 boost packages, you have to have all of them, just to use the part you used before. I'm trying to remedy that.

This need you feel to glob together libraries and/or pieces of libraries for the abstract goal of reducing dependencies is just wrong IMO.

Please don't panic. The goal is not abstract and the method, as I tried hard in my initial mail to make clear with a special note to try to avoid responses like yours, is something to be done with thought and consideration for concerns like yours (obviously). Thanks, Steve.

On 10/18/2013 07:39 AM, Vicente J. Botet Escriba wrote:

Le 18/10/13 00:24, Stephen Kelly a écrit :

...

Hi there,

my plan for modularizing and modernizing Boost was roughly this:

* Phase 0 - remove dead weight by bumping compiler feature requirements * Phase 1 - move some files around so that the modularized repos form a mostly directed graph * Phase 2 - Form some kind of 'boost core library' or 'boost feature normalization library' from the guts of existing libraries like type_traits, static_assert, config mpl and utilities. * Phase 3 - Try to port the mpl to variadic templates so that the dependency on Boost.PP is not needed when variadic templates are available.

I recommend completing up to phase 2 before migrating to git, as otherwise files will have to be deleted from one repo, and added to another without history.

Phase 0 is aborted, so let's look at phase 1.

[Note: This should go without saying, but my experience on this list tells me it needs to be said:

* I do not propose making many commits with the commit message 'migrate' * The below is scripted for your understanding only. Scripting gives an exactness which prose does not, and allows reproducibility. Don't take it too literally. * Of course, forwarding headers should be understood to be left behind when a file is moved, where possible. * Don't cry too loudly about where I'm moving files to. See Phase 2 above, and understand that this is partly only an experiment to see how modularization can be done.

EndNote]

The remaining problematic edges are:

conversion->range conversion->math range->algorithm math->multiprecision concept_check->parameter

Assuming they can be broken by moving some files aroung (I believe they can be), we end up with a small graph of strongly connected components:

http://steveire.com/boost/graph_after_remaining.dot http://steveire.com/boost/graph_after_remaining.png

There are now 18 edges and 11 nodes.

Looking at the entire graph again, we get this:

http://steveire.com/boost/graph_final.dot http://steveire.com/boost/graph_final_small.png

Obviously, this is not perfect, but it is a beginning, and it is mostly now a directed graph.

Thanks for working on this.

Thanks for the appreciation.

The dependency between thread and interprocess can be broken if we extract unique_ptr from interprocess and move it to smart_ptr.

unique_ptr.hpp includes several other interprocess lib headers. Those would have to be either moved or resolved too.

The dependency of thread to chrono/date_time could be broken after the work started by Andrey in the sync directory. But I suspect that this will not be ready for the next release.

The new parts will be * sync: contains basic synchronization tools, as mutexes, condition_variables, locks, * system_chrono : contains something similar to Boost::Chrono but restricted to nanoseconds (less meta-programming needed)

Would these be two new git repos/packages?

The new dependencies will be

* chrono -> system_chrono * date_time -> system_chrono * sync -> system_chrono * thread -> system_chrono

And what will system_chrono depend on?

and later on * thread -> sync ?

Note system_chrono doesn't exists yet (it is included in sync) and could also be moved to detail.

Do someone know which parts of Boost.Thread are used by Boost.Spirit and Boost.Pool? Knowing this would help us to see if these libraries could depend on the new sync repository.

Why don't you check things like this yourself, instead of asking on a mailing list and introducing a human round trip? This isn't the first time you've asked things like this. I'm really curious why you try to introduce a human round trip rather than run a simple 'git grep' or whatever equivalent tools that you presumably have at your disposal.

BTW, I don't see Boost.Atomic in the picture.

What picture? Boost.Atomic appears in the graph_all.dot. Thanks, Steve.

On 10/18/2013 11:58 AM, Bjorn Reese wrote:

On 10/18/2013 09:58 AM, Stephen Kelly wrote:

...

unique_ptr.hpp includes several other interprocess lib headers. Those would have to be either moved or resolved too.

There is work-in-progress on unique_ptr:

http://lists.boost.org/Archives/boost/2013/08/205486.php

Its current dependencies are Boost.Move, Boost.TypeTraits, and Boost.Config.

Interesting, thanks, Steve.

On 18 October 2013 18:45, Vicente J. Botet Escriba wrote:

I don't see the dependency to Boost.thread, but Boost.Atomic depends on Boost.Thread in some specific platforms.

He's only concerned with header dependencies.

Le 18/10/13 20:31, Andrey Semashev a écrit :

On Friday 18 October 2013 19:45:01 Vicente J. Botet Escriba wrote:

...

I don't see the dependency to Boost.thread, but Boost.Atomic depends on Boost.Thread in some specific platforms. Only Boost.Atomic tests do. I removed the dependency on Boost.Thread some time ago (will be released in 1.55).

Thanks Andrey. I shall had do the check myself before writing on this ML. Best, Vicente

On 10/18/2013 10:18 AM, Daniel James wrote:

On 17 October 2013 23:24, Stephen Kelly wrote:

...

* Phase 2 - Form some kind of 'boost core library' or 'boost feature normalization library' from the guts of existing libraries like type_traits, static_assert, config mpl and utilities. I think the intent was for 'detail' to be a sort of core module, but several of its headers do drag in too many dependencies. I'd be inclined to move them out of detail, but that's up to you.

...

Move enable_if from utility to type_traits: It might be worth breaking up modules like utility and iterator rather than moving the headers into new modules.

Do you mean turn them into multiple repos/packages instead of one, or do you mean something different?

The smaller modules could still feed into your boost core/feature normalization module. Although that might be too difficult to do as part of the conversion.

To be clear, I propose doing most/all of these modularization changes before the conversion to git. Are you proposing to do them concurrently/at the asme time as migrating to git?

The original plan was to break the functional module up, but there was a problem with doing that in the conversion, so I was going to look into doing it afterwards instead,

What problem was encountered?

which I think can be done while preserving history.

How so? Replaying the history on top of master? That's still a loss of history really, but it's better than a straight addition-of-current-version.

...

git submodule foreach 'git grep -l -P boost/detail/workaround.hpp -- include/boost | xargs sed -i "s|boost/detail/workaround.hpp|boost/config/workaround.hpp|" || echo' mv libs/detail/include/boost/detail/workaround.hpp libs/config/include/boost/config/ I think moving workaround.hpp to config is just a case of moving a line in this file:

https://github.com/ryppl/Boost2Git/blob/master/repositories.txt

Actually, we should probably create a pull request today, as it seems like a sensible and uncontroversial change to me. Perhaps also 'boost/limits.hpp' and 'boost/version.hpp'. We can leave the workaround header's path as 'boost/detail/workaround.hpp',

Yes, good point.

there are already 'detail' paths in multiple modules. The headers can be moved round within a module after the conversion.

Btw. Unless I've misunderstood the command you're using (sorry if I have), you're not updating '.cpp' files which might skew the results.

You are correct. Currently I'm only analyzing 'public dependencies'. Any dependency in the cpp files is a 'private dependency' - a build time dependency that does not propagate to users of the binary. Thanks, Steve.

On 10/18/2013 11:05 AM, Daniel James wrote:

...

...

The smaller modules could still feed into your boost core/feature normalization module. Although that might be too difficult to do as part of the conversion. To be clear, I propose doing most/all of these modularization changes before the conversion to git.

Are you proposing to do them concurrently/at the asme time as migrating to git? Yes, or at least before modularization is in use. But I'll go along with whatever works for the people doing this.

That's good, but I don't think it's a position shared by everyone :).

...

...

The original plan was to break the functional module up, but there was a problem with doing that in the conversion, so I was going to look into doing it afterwards instead, What problem was encountered? it was here:

http://lists.boost.org/Archives/boost/2013/05/204230.php

IIUC the problem is that the modules need to be used to recreate old versions of boost. So if hash's files were moved into a new module, the files that are currently in libs/functional/hash would be in the wrong place. But I think it should be fine if they're moved to 'libs/functional_hash' in the future.

Thanks for the link. If any part of my plan can move forward (reading the mail from Beman, that is not a certainty), I can look into that issue.

...

...

which I think can be done while preserving history. How so? Replaying the history on top of master? That's still a loss of history really, but it's better than a straight addition-of-current-version. Possibly by including all the module history in each smaller module and, if possible, rewriting the history to only include the relevant headers (this would be done before the module is in use).

I don't really see a sense in having a non-zero time interval between considering a module converted to git and considering it 'in use'. As far as I understand your mail, you want to do this splitting after conversion, but before considering it 'officially in use' or something? You are talking about re-writing history of a git repo. I still recommend modularizing first.

This means there will be duplicate history in different modules, but I don't think that would cause any real problems. I admit I haven't thought this through or done any experiments, I was leaving that for later.

Ok. Thanks, Steve.

On 10/18/2013 03:12 PM, Daniel James wrote:

On 18 October 2013 13:23, Stephen Kelly wrote:

...

...

...

...

which I think can be done while preserving history. How so? Replaying the history on top of master? That's still a loss of history really, but it's better than a straight addition-of-current-version. Possibly by including all the module history in each smaller module and, if possible, rewriting the history to only include the relevant headers (this would be done before the module is in use). I don't really see a sense in having a non-zero time interval between considering a module converted to git and considering it 'in use'. As far as I understand your mail, you want to do this splitting after conversion, but before considering it 'officially in use' or something? Sorry I should have been clearer, I meant before the smaller modules are in use. I'll break it down into the rough steps for functional_hash:

1. Git conversion creates the functional module, everyone uses this. 2. I manually create the functional_hash module, probably extracted from the functional module in some manner. 3. In a branch in the functional module, delete all the hash files (but keeping html redirect files to avoid breaking links). 4. In a branch in the main boost repo, add the functional_hash submodule, and update the functional submodule, and the appropriate build files etc. 5. Once everything is okay merge the branches.

Why all the branches? That seems to just add a lot of complexity as a result of trying to do this after converting to git. Why not create the functional_hash module now, before converting to git? Then there are never two modules to keep in sync. Thanks, Steve.

On 10/18/2013 03:33 PM, Daniel James wrote:

On 18 October 2013 14:18, Stephen Kelly wrote:

...

Why all the branches? That seems to just add a lot of complexity as a result of trying to do this after converting to git.

Why not create the functional_hash module now, before converting to git? Then there are never two modules to keep in sync. I'd rather take on the entire burden of doing this, than put even a small portion of it on the modularization effort.

This way they won't to deal with a module splitting, and won't have to work out how to deal with header files moving from one module to another.

I don't think that is hard for the tool.

Chances are the functional_hash module's history would only go back to the creation of the module, which isn't what I'd want.

I don't see why it wouldn't go further back. Maybe your opinion is based on misunderstandings. Thanks, Steve.

Date: Fri, 18 Oct 2013 10:05:08 +0100 From: daniel@calamity.org.uk To: boost@lists.boost.org Subject: Re: [boost] [modularization] Modularizing Boost (modularization)

...

...

which I think can be done while preserving history.

How so? Replaying the history on top of master? That's still a loss of history really, but it's better than a straight addition-of-current-version.

Possibly by including all the module history in each smaller module and, if possible, rewriting the history to only include the relevant headers (this would be done before the module is in use). This means there will be duplicate history in different modules, but I don't think that would cause any real problems. I admit I haven't thought this through or done any experiments, I was leaving that for later.

Examining and modifying git repo history is something I've done quite a few times now and will end up continuing to do in the future. The primary issue in the case of boost would be making sure that the super-module references are still valid for anyone looking at history (i.e. you don't want to change every hash in the submodule and make the super-module invalid). I'd say that given the sizes of the individual git repos for the libraries in boost, that keeping the entire history in each of the split libraries would be feasible and not cost much at all. It's useful to note that the entire git history for boost with an entire working directory with the latest boost code is smaller than an svn trunk checkout. So, overall, I'm not sure why losing history would ever be a discussion point given that keeping it costs so little.

On 10/18/2013 01:18 PM, Beman Dawes wrote:

I wasn't aware that phase 0 was aborted. Why was that?

If I understood it correctly, it was due to concerns from various library maintainers that the removal of compiler workarounds from matured libraries may introduce new and subtle flaws that would have to be ironed out.

Stephen Kelly wrote:

Have files ever been moved around in the svn repo before?

Yes. For example, see the history of boost/bind/bind.hpp, which was at boost/bind.hpp before revision 51487.

On 10/18/2013 07:25 PM, Beman Dawes wrote:

Have you looked at https://github.com/ryppl/Boost2Git/blob/master/repositories.txt for example?

Yes. I even linked to a mail from Dave which explains it: http://thread.gmane.org/gmane.comp.lib.boost.devel/245078/focus=245098

The impression I have is that every change, even fairly minor stuff, breaks something else.

The impression I have is that it is deterministic. If we change that file and we get it wrong, we deterministically know about it within a few hours. That is a tiny cost for the benefit of having acyclically-modularized git repos without re-writing the history a few times after launching them. The git repos will last years or decades, not hours. This scm transition has taken years so far, and because it's being approached 'big bang' style instead of incrementally, few actual changes have actually landed in all the years. Doing things incrementally results in getting things done better, affecting fewer people at a time, and with more verification points. Thanks, Steve.

on Sat Oct 19 2013, Daniel Pfeifer wrote:

2013/10/19 Stephen Kelly :

...

On 10/18/2013 07:25 PM, Beman Dawes wrote:

...

Have you looked at https://github.com/ryppl/Boost2Git/blob/master/repositories.txt for example?

Yes. I even linked to a mail from Dave which explains it:

http://thread.gmane.org/gmane.comp.lib.boost.devel/245078/focus=245098

...

The impression I have is that every change, even fairly minor stuff, breaks something else.

That might be true for Boost2Git's source code,

That has not been true since I rewrote most of that tool from scratch.

but the file repositories.txt should be straight forward.

Yes -- Dave Abrahams

On 18 October 2013 12:18, Beman Dawes wrote:

The other phases are well worth discussing, particularly once the conversion is complete and that giant step is behind us.

I think we should consider at least some of the changes now. Moving headers to a new module (without changing the path) shouldn't be disruptive. I thought that moving 'boost/detail/workaround.hpp', 'boost/limits.hpp', 'boost/version.hpp' from details to config seemed like an obviously good idea. They seem like a natural fit, version.hpp is supposed to be part of config anyway: http://www.boost.org/doc/libs/1_54_0/libs/config/doc/html/boost_config/boost... boost/limits.hpp is intended to be part of compatibility, but is currently in the detail module. So it has 3 potential homes.

On 10/18/2013 02:01 PM, Julian Gonggrijp wrote:

Stephen Kelly wrote:

...

[...] * Phase 1 - move some files around so that the modularized repos form a mostly directed graph [...] I apologise for this mostly tangential remark, but it appears that you specifically mean a mostly *acyclic* (directed) graph.

Yes, that is what I meant. Thanks for clarifying.

I would expect that a dependency graph is always directed (even if some dependencies are mutual) and that the aim of your project is to remove cycles, so that using one node doesn't always imply that you need all other nodes as well.

Yes.

However, this conflicts with my intuition every time I read that you want to make the graph (more) "directed".

To summarise, you would help me to feel more sure that I understand what you are doing if you could confirm that by "directed" you actually mean "acyclic". Or, if that is not the case, I think I need a bit more explanation!

I can confirm that your wording is better. My aim has been to make the dependency graph more acylcic.

Please know that I totally agree with the aim to reduce dependencies between Boost libs. Regard this post as a nitpick by an idiot who works too often with graphs, if you want. :-)

Not at all! I aim for exactness where it matters. I got it wrong in this case, where it indeed matters. Thanks, Steve.

On 10/18/2013 02:19 PM, Beman Dawes wrote:

On Thu, Oct 17, 2013 at 6:24 PM, Stephen Kelly wrote:

...

Hi there,

my plan for modularizing and modernizing Boost was roughly this:

* Phase 0 - remove dead weight by bumping compiler feature requirements * Phase 1 - move some files around so that the modularized repos form a mostly directed graph * Phase 2 - Form some kind of 'boost core library' or 'boost feature normalization library' from the guts of existing libraries like type_traits, static_assert, config mpl and utilities. * Phase 3 - Try to port the mpl to variadic templates so that the dependency on Boost.PP is not needed when variadic templates are available.

Herb Sutter has pointed out that approximately 15 months from now all widely used compilers and their libraries will be C++11/14 compliant, modulo residual bugs.

Widely used is irrelevant on this list. See the responses to threads I've started.

At that point C++11/14 boost (2.x?) becomes a viable option.

I'm looking forward to seeing you try to get buy-in for that :).

C++11/14 boost would have a markedly different dependency graph, since libraries would only use the boost versions of other libraries if they needed some extension not present in the standard library version.

That's part of my thinking too. Eg, mpl would not depend on Boost.PP if used by a C++11 compiler if my phase 3 is completed. That is the kind of thing we can encode into the cmake package files.

It might be helpful to start figuring out how we can do the transition to a C++11 (and then 14) world.

I agree. I think that's phase 3+ though, and I recommend doing the other phases first. Thanks, Steve.

On Fri, Oct 18, 2013 at 4:10 PM, Joel Falcou wrote:

Versionning exist for a reason. Modern boost development using C++11 and forward should move to a 2.0 version. Old compilers will be supported in the 1.x branch. End of the story.

[sidenote] I agree with Joel, I always assumed (few years ago) that that's what would happen and I'm still surprised it's not seriously considered. I guess that's a discussion for post-modularization but I fear that this discussion will get in limbo and hurt boost like the issues with the review process. [/sidenote]

On Fri, Oct 18, 2013 at 11:07 AM, Niall Douglas wrote:

I think Beman might have an idea in a v2.x Boost - one whose libraries *solely* consist of C++11 upgraded libraries. Any libraries from Boost v1.x not upgraded to C++11 get dropped from v2.x.

No, my thought was that Boost 2.x would allow existing libraries to be changed to support only C++11 compilers, and that new libraries would only have to work with C++11 compilers. Existing libraries could continue to support C++03 compilers if they want to, and aren't required to add C++11 features.

I look forward to the aghastness at the idea of dropping libraries from Boost :)

Hey, we've dropped libraries before:-) But that's only because something better came along and the old library had been deprecated for a long time. --Beman

On 18 October 2013 13:19, Beman Dawes wrote:

Herb Sutter has pointed out that approximately 15 months from now all widely used compilers and their libraries will be C++11/14 compliant, modulo residual bugs. At that point C++11/14 boost (2.x?) becomes a viable option.

Remember that compliant doesn't mean it's always available or even enabled by default. Lots of code that's built with G++ is still pure C++03 and likely to remain so (some won't even compile in C++11 mode due to combining string literals and macros in ways that conflict with the C++11 UDL grammar.) I don't think that should stop your vision for Boost in a C++11 or 14 world though.

C++11/14 boost would have a markedly different dependency graph, since libraries would only use the boost versions of other libraries if they needed some extension not present in the standard library version.

It might be helpful to start figuring out how we can do the transition to a C++11 (and then 14) world.

I would love to see this happen, but I'm not going to hold my breath :-)

On 10/18/2013 11:59 AM, Stephen Kelly wrote:

On 10/18/2013 05:42 PM, Edward Diener wrote:

...

The property_map library can be used completely outside of the graph library. What does moving parts of property_map into graph accomplish ?

It makes the property_map library/repo/package not depend on the graph library/repo/package.

The property_map library is a header only library. Please point out to me where in the property_map headers there is any reference to anything in the graph library.

'can be used' is the wrong thought process. You need to consider the union of dependencies of include files in a package. Those are the dependencies of the package.

Note also that I am repeating myself. My initial mail contained this:

...

There are 104 nodes and 1159 edges. Each edge is a real dependency which exists between repos, and which will exist between boost modularized packages. They should not be considered optional.

http://thread.gmane.org/gmane.comp.lib.boost.devel/245078

I also mentioned dependencies between repos/libraries several times in that mail, and particularly pointed out that I'm not talking about file-level dependency in this mail in response to you:

http://thread.gmane.org/gmane.comp.lib.boost.devel/245078/focus=245101

On 10/18/2013 12:37 PM, Stephen Kelly wrote:

On 10/18/2013 06:28 PM, Edward Diener wrote:

...

On 10/18/2013 11:59 AM, Stephen Kelly wrote:

...

On 10/18/2013 05:42 PM, Edward Diener wrote:

...

The property_map library can be used completely outside of the graph library. What does moving parts of property_map into graph accomplish ?

It makes the property_map library/repo/package not depend on the graph library/repo/package.

The property_map library is a header only library. Please point out to me where in the property_map headers there is any reference to anything in the graph library.

Le-sigh.

I suggest you do your equivalent of this:

boost-trunk/boost/property_map{master}$ git grep boost/graph

I won't ruin the surprise for you by pasting the output.

If you don't understand my point after seeing the output, please just accept that you don't understand the point. No need to respond. A long sub-thread like this is bad.

No a sub-thread like this is not bad. When you feel entitled to do things without valid justification that is bad. And when you talk in condescending terms to others that is bad. If you cannot or are unwilling to explain and defend the reasons why you are doing what you are doing in terms of Boost libraries/files I for one don't think you should be able to do those things.

On 10/18/2013 3:28 PM, Jonathan Wakely wrote:

On 18 October 2013 18:04, Edward Diener wrote:

...

On 10/18/2013 12:37 PM, Stephen Kelly wrote:

...

I suggest you do your equivalent of this:

boost-trunk/boost/property_map{master}$ git grep boost/graph

I won't ruin the surprise for you by pasting the output.

If you don't understand my point after seeing the output, please just accept that you don't understand the point. No need to respond. A long sub-thread like this is bad.

No a sub-thread like this is not bad. When you feel entitled to do things without valid justification that is bad. And when you talk in condescending terms to others that is bad. If you cannot or are unwilling to explain and defend the reasons why you are doing what you are doing in terms of Boost libraries/files I for one don't think you should be able to do those things.

Did you run the command he suggested? Is the output not justification?

I am not using git but svn, like the majority of people. I missed the property_map 'parallel' sub-directory in my editor's search.

On 10/19/2013 06:43 AM, Rob Stewart wrote:

On Oct 18, 2013, at 1:04 PM, Edward Diener wrote:

...

On 10/18/2013 12:37 PM, Stephen Kelly wrote:

...

On 10/18/2013 06:28 PM, Edward Diener wrote:

...

On 10/18/2013 11:59 AM, Stephen Kelly wrote:

...

...

The property_map library can be used completely outside of the graph library. What does moving parts of property_map into graph accomplish ? It makes the property_map library/repo/package not depend on the graph

On 10/18/2013 05:42 PM, Edward Diener wrote: library/repo/package. The property_map library is a header only library. Please point out to me where in the property_map headers there is any reference to anything in the graph library. Le-sigh.

I suggest you do your equivalent of this:

boost-trunk/boost/property_map{master}$ git grep boost/graph

I won't ruin the surprise for you by pasting the output.

If you don't understand my point after seeing the output, please just accept that you don't understand the point. No need to respond. A long sub-thread like this is bad. No a sub-thread like this is not bad. When you feel entitled to do things without valid justification that is bad. And when you talk in condescending terms to others that is bad. If you cannot or are unwilling to explain and defend the reasons why you are doing what you are doing in terms of Boost libraries/files I for one don't think you should be able to do those things. I've been following a number of Steve's threads. What I've observed is that Steve's replies, to those that disagree or stymie his progress

Disagreeing is fine. Not reading what one is responding to and asking me to run grep are (examples of) the problem. Things like that derail threads. Just look what happened to this one for example :). Thanks, Steve.

Le 19/10/13 09:19, Stephen Kelly a écrit :

There are others I've encountered though in my short time on this list.

Vincente has also asked me to run grep for him a few times by now too:

http://thread.gmane.org/gmane.comp.lib.boost.devel/244856/focus=244888

Well I expect that if you are responsible of this analysis, it is better IMHO that one person do the grep and provide the global information to all the concerned people. I see that we disagree on that and a lot of other things. Life is life.

and it took a couple of mails to land the difference between today and yesterday:

http://thread.gmane.org/gmane.comp.lib.boost.devel/244216/focus=244242

These mails only create confusion. They are being sent without enough thought. Here's an example where a confused response resulted from not reading the attached commit. Beman read the response, and I guess also did not read the commit, and also got caught up in the confusion:

I recognize that I missed the date. BTW, from the contents of your messages I understand that you could not be wrong never as you have always taken the time to analyze carefully the contents of all the threads, inspected carefully the dates of the each one of the post and in addition that your understanding of what other can thing is always the good one. Note that your posts are much more confusing because you are pushing all the authors to follow what you are doing without any respect for their opinion. I would like to know who gave you the right to update the whole repository without contacting each one of the authors (I was surely on vacation when you got this right). Before been able to update the Boost repository the people must know how the Boost community works. It seems that you ignored how we work and in this sens I understand better now why you were applying practice you use to use on other communities. I have send some replays to your posts and you are ignoring most of them. Best, Vicente

Le 30/10/13 14:07, Ahmed Charles a écrit :

...

Date: Sat, 19 Oct 2013 11:44:11 +0200 From: vicente.botet@wanadoo.fr To: boost@lists.boost.org Subject: Re: [boost] A bike shed (any colour will do) on greener grass...

I recognize that I missed the date.

BTW, from the contents of your messages I understand that you could not be wrong never as you have always taken the time to analyze carefully the contents of all the threads, inspected carefully the dates of the each one of the post and in addition that your understanding of what other can thing is always the good one.

Note that your posts are much more confusing because you are pushing all the authors to follow what you are doing without any respect for their opinion.

I would like to know who gave you the right to update the whole repository without contacting each one of the authors (I was surely on vacation when you got this right). Before been able to update the Boost repository the people must know how the Boost community works. It seems that you ignored how we work and in this sens I understand better now why you were applying practice you use to use on other communities.

I have send some replays to your posts and you are ignoring most of them. I've been reading the boost lists for years now and I almost never send mails to them because of a variety of factors, but most importantly, things almost never reach a reasonable conclusion or consensus. Actually adding value seems really hard in any thread that gets the attention of any number of people while not being focused on one or two people. Basically, asking a specific question of a maintainer often works cause it's almost like a two way conversation happening in public, but any thread which is unfocused in any way, is inevitably going to get derailed, often hilariously. (or why else would I read them, right?)

Stephen's experience isn't unique and it's probably common, the primary difference is that he's actually pointing it out. His responses aren't ideal or perfect but given the complexity of most of the code in boost, one might well expect people on this list to understand how to search without mailing the list first.

Boost reminds me of a corporation (guild) that I was part of in Eve Online, where the old members had done lots of glorious stuff in the past but no longer had the time or inclination to put into current pursuits, but at the same time, none of the new members had the standing in the group to take control and move it forward while the old guard also had an interest in maintaining some amount of control and former glory. Granted, Boost is different, but as far as analogies go, it really does seem eerily similar.

Short of boost being forked by a group of energetic people interested in making massive changes, how exactly will it ever migrate to C++11/14 with the current ownership model where people have to contact ~100 library maintainers if they want to make changes across the entire project? If all I wanted to do was create a branch to work on C++11/14 work or anything like it, not only would it require touching ~100 git repos, I'd have to send ~100 emails and create ~100 trac tickets with patches and then manage ~100 different conversations with ~100 different people, across different countries, timezones, native languages, cultures, etc. How do you ever expect anyone to ever want to do that?

If you ignore the political side of what Stephen is trying to do and just concentrate on the technical side, it's daunting in scope and he's been willing to do it in spite of no reasonably belief that progress would be made and with tons of resistance. So, perhaps he didn't follow the process and he should have gone about it differently. But I would argue that Boost should have a process for changes that are so massive that working with individual maintainers isn't feasible. Expecting someone to make progress doing what he wants to do while following the usual boost process is simply ridiculous. Note: I just noted STL's patches taking weeks/months to get applied and they only touched two files.

I know what it's like to spend an entire day simply managing code changes, where they are and how they all fit together into the big picture in order to ensure progress in the face of external delays, like code reviews and testing. I'm pretty sure if I wasn't getting paid to do it, I wouldn't do that part of my job and that's basically what you are asking someone to do, only like 50 times worse.

Hi, I recognize the Boost process is not well adapted to these kind of changes. If you want to change the Boost process please make a concrete proposal that takes into consideration this use case to this list. Best, Vicente

2013/10/31 Ahmed Charles :

...

I recognize the Boost process is not well adapted to these kind of changes. If you want to change the Boost process please make a concrete proposal that takes into consideration this use case to this list.

I know you mean well, but I believe the problem is that anyone who has the political capital required to change the process isn't invested in changing it and everyone who is invested in changing it doesn't have the required political capital to change the process.

If the founder of boost was given a billion dollars and decided that boost was the only thing worth working on and that modularization in the way Stephen proposes is important, I'm sure he could convince or otherwise spend political capital to get the change done with minimal coordination overhead and library maintainers would shrug and move on with their lives cause spending their political capital arguing with the founder of boost isn't worth it.

But that situation isn't going to happen and even if I did make a proposal, it would be unlikely to be well received because I don't have the political history to understand what maintainers would agree to or not. It's simply not worth my time to try to fight political battles in boost when I could spend it doing something fun, like playing borderlands 2.

Boost problems can only be solved by the current leaders of boost recognizing issues and trying to solve them using their political capital and time. If none of the current leaders are interested in defining a policy which is friendly to these types of changes, then it will never happen, unless someone has way too much time on their hands and wants to waste tons of it gaining enough influence that they can change things. And that's just hard, even with an arbitrary amount of time.

If you read this mailing list carefully, you will notice that the founder of Boost indeed has a C++11/14 Boost in mind and is involved in the ongoing modularization process. He is probably lacking this billion dollars.

On 31 October 2013 05:22, Ahmed Charles wrote:

My point was that the set of people with time does not intersect with the set of people who have political capital. Rather than simply restating what I stated, perhaps you could comment on a potential solution to the fact that these sets do not overlap and how people with more time and energy to handle larger scoped changes could successfully impact boost without having to go through a political nightmare and unhelpful replies like you just gave.

If you're having problems with politics, then a good solution is to not be terrible at politics.

Date: Thu, 31 Oct 2013 00:14:27 -0700 From: mcaisse-lists@ciere.com To: boost@lists.boost.org Subject: Re: [boost] A bike shed (any colour will do) on greener grass...

On 10/30/2013 07:28 PM, Ahmed Charles wrote:

...

I know you mean well, but I believe the problem is that anyone who has the political capital required to change the process isn't invested in changing it and everyone who is invested in changing it doesn't have the required political capital to change the process.

Ahmed, I appreciate your comments and the time your took to articulate them. Considering the care you have demonstrated in your initial post as well as your responses, I suspect your thoughts have added "value" already.

In May 2011, a group was formed called the Steering Committee. While I was not involved in the detailed discussions that led to the formation, I do recall the ML activity and BoostCon sessions preceding the announcement. Consensus was the rule prior to the formation of the Steering Committee. I have tremendous respect for those who brought about Boost and their humility shown within the operation of the organization. Their realization that consensus had become unattainable and the organization was stagnating drove the formation of a group of peers to help guide Boost. While it might seem as if Boost is aimlessly wandering or lacks direction save the incidental movement caused by the summation of each author's will, there is a group that can intervene and provide uniform purpose.

I work in the same office as a member of the steering committee (you knew that though :) ) and I've talked to him (Jon Kalb) about this on a few occasions. My impression of the steering committee is that while it was formed to serve lots of purposes, it currently mainly serves in support of C++Now/BoostCon and hasn't really had much impact on the combined technical/political issues that face boost libraries. If there are examples (hopefully more than one) which contradict this, I would like to know. This isn't to disparage the steering committee, of course, but I know it is the intended solution and I'm trying to get things to go in that direction more and more, since it seems there isn't enough being done.

Unlike other organizations, Boost fully respects the will of an author in maintaining their library. I would be dishonest if I didn't acknowledge that this policy has resulted in some personal head scratching with a few libraries over the years. In the end though, I believe that library authors best understand the constraints and intent of their libraries and how to maintain them.

I'm personally on the fence about this policy. I see some library authors that are responsive and reasonable with their library and I wouldn't want to disenfranchise them one bit. But I also see that it can create an 'old guard' sort of situation that benefits no one. With power should come responsibility and there should be a mechanism that ensures that libraries that stagnate are given new maintainers. I understand that there is a shortage of people signing up to maintain libraries, but I think at least part of that is due to the impression that libraries are only ever 'pried from the hands of their dead maintainers'.

Sometimes we must persuade an author of a good idea or to increase their vision of their library. We want authors that are involved and passionate. I am personally uncertain about the democratization that occurs via libraries in Git. The ease of forking a repository has the potential of diluting the ecosystem, creating superior libraries through collaboration, or resulting in a form of natural selection. It will largely depend on the library's maintainer.

I look forward to being able to 'fork' boost locally and be able to manage changes to various libraries, completely ignoring the possibility that those changes will ever leave my hard drive. I simply enjoy tinkering and that's enough incentive for me to want to use git to do that with boost. It's only inevitable that people will take it further and take things in a direction that the library maintainer doesn't want and hopefully that will provide the competition and incentive required for boost to adapt. Granted, I also think that the complexity of using submodules will stem most of the diluting of the ecosystem, since it will be hard for people to manage publishing releases via simply having a tag on github that allows people to download a zip file and get a completely working boost implementation. I did my first pull request on github earlier to fix a typo in the readme file used in the boost/admin project and it's already been integrated by Dan. All without leaving the browser. Fixing documentation or other trivial issues could become so simple that it's a no-brainer for anyone interested in contributing while noticing that issue.

Each year a couple of people cycle out of the Steering Committee and a couple cycle in. Sebastian Redl and I cycled in this past May. Your comments as well as those of others in this thread have me thinking. I can appreciate the overall frustration that many have shown in the past couple months on the ML. Boost is a slow moving organism. Please know that there are those involved who are keenly concerned about the "political side" and how best to create a healthy, active, and viable organization. I would hate to see new and energetic partners become disenfranchised.

I agree and eagerly look forward to progress in this area. :)

On 31 Oct 2013 at 2:08, Ahmed Charles wrote:

I'm personally on the fence about this policy. I see some library authors that are responsive and reasonable with their library and I wouldn't want to disenfranchise them one bit. But I also see that it can create an 'old guard' sort of situation that benefits no one. With power should come responsibility and there should be a mechanism that ensures that libraries that stagnate are given new maintainers. I understand that there is a shortage of people signing up to maintain libraries, but I think at least part of that is due to the impression that libraries are only ever 'pried from the hands of their dead maintainers'.

I am personally strongly in favour of libraries getting deprecated and removed from releases if they are not maintained - let's say no bug fixes by its maintainer in two major release cycles adds them to the list of soon to be deprecated libraries, and no bug fixes by its maintainer in three major release cycles has them removed from Boost central and put into an attic. That encourages new maintainers to step forwards, and old maintainers to give up their control if they can't keep up due to life commitments. It would require some political bravery from the SC though, as users will get upset. I would also personally count lack of adding direct C++11 support as equal to lack of bug fixing, but I appreciate that will be controversial (what is C++11 support anyway???) :) Niall -- Currently unemployed and looking for work. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/

On 31 Oct 2013 at 10:40, Marshall Clow wrote:

...

will get upset. I would also personally count lack of adding direct C++11 support as equal to lack of bug fixing, but I appreciate that will be controversial (what is C++11 support anyway???) :)

A good question. For example, what does it mean to add C++11 support to Boost.Array?

#if __cplusplus >= 201103L #warning "You should really think about using std::array instead of boost::array." #endif

:-) :-)

Or better still, simply silently map in std::array as boost::array and definitely don't mention it in any documentation :) After all, library code ought to be surprising, keep these programmers on their feet! More seriously though, I do wish more rvalue ref support was present in the older Boost libraries. I have, occasionally, bumped into situations where passing in a move-only type causes barf and I have to use a shared_ptr wrapper to work around it. That's a problem with any old C++ codebase of course, but it would be nice if Boost had a formal process in place to strongly incentivise minimum necessary C++11 upgrades of older Boost libraries. That said, I appreciate adding move only type support often involves a complete rearchitect of internals. That may of course not be a bad thing. Niall -- Currently unemployed and looking for work. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/

On 31 Oct 2013 at 19:00, Stephen Kelly wrote:

...

I am personally strongly in favour of libraries getting deprecated and removed from releases if they are not maintained - let's say no [snip] With 68 libraries in a circular-dependent mesh, how do you expect that would work?

Judging from that dependency graph you posted a while ago, you're right there is a small core of libraries where deprecation due to lack of maintenance can't work. It's a reasonable bet however that none of those core libraries has ever seen two major releases pass without a bug fix, so therefore those are moot. If, however, there IS a core library highly used by other libraries which has seen open bugs with no fixes for more than two major releases, I would hope some serious alarm bells start ringing - either way, right now we don't automate such a process, so if it were happening would we even know? I suspect that core library list is far smaller than 68, but you're the expert here. Do you know how tightly integrated those 68 libraries are e.g. how many of them pull in a dependency only to never use it or use it very lightly? How many pull in dependencies which can now be replaced with C++11 standard libraries instead? That sort of thing. (P.S.: I don't expect you to know the precise answer to this, but I'm very sure you know much more than I do). Niall -- Currently unemployed and looking for work. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/

On 31 Oct 2013 at 13:27, Nevin Liber wrote:

...

It would require some political bravery from the SC though, as users will get upset.

First you'd have to get the SC to agree with you. It would be weird for an organization that provides a fairly stable base of libraries to users to arbitrarily go mess with that stability. IMHO, of course.

Oh sure. Arguments like these of mine are done with the expectation few will agree with me, and with near zero chance of changing outcomes. You'll see the same when I make these sorts of arguments to WG21 study groups where usually I am told just how many ways I am wrong. It's still worth doing, or I wouldn't get such detailed and lengthy negative responses.

Why is usage within Boost itself any more important that usage by users?

Boost needs to eat its own dog food, including dealing with consequences of its own internal self management policies. Boost users do not - they are free to hack Boost into any bespoke configuration which suits them. I'll clarify this more specifically: Boost may choose to act as a shining light of how to do C++, and as a result may enact a deprecation and C++ feature upgrade strategy which would be considered aggressive by most standards. Users are affected by this, sure, but they can and do keep custom Boost distros (e.g. including non peer reviewed libraries) which track HEAD without necessarily doing so verbatim. In other words, they don't have to buy in to the degree Boost must buy into itself. Beman and others have mentioned a vision of a Boost v2.x. I got the sense such a v2.x edition would be leaner than the present edition. The deprecation strategy I proposed is one of many ways of deciding what ought to get cut, and it does come with the huge advantage of fairness.

I don't see how the issue is any different; if you remove a library, you break somebody. Why is it "good" to break outside users but "bad" to break internal users? To me, both are bad.

Change always implies breakage by definition. Even if the breakage is in buggy behaviour becoming broken (i.e. fixed). Not breaking *always* equals stagnation. I've noticed that most software engineers prefer to design software to be easily added to more than easily removed from. That strategy works long term if and only if transistor and storage densities keep rising exponentially. I've often spoke privately with various people (e.g. at C++ Now) about what will come to our industry when that gravy train runs out and hardware capacity growth goes linear. I think the biggest change to our practice will be implementing steady state software - software which neither grows nor shrinks in footprint, but evolves, and I expect a ton of present large multinationals to go bankrupt as they fail to adjust quickly enough. The good news is that I think some of the very best and most interesting software will be made once hardware advances stop subsidising us, and I in particular have detailed hopes for what to do when that watershed comes. Anyway, getting off topic, but my point is that there appears to be a general feeling that Boost has become too big. Many feel modularisation will fix this. I personally have severe doubts on that, but I guess we'll all see how it pans out and we'll go from there. Niall -- Currently unemployed and looking for work. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/

On 31 Oct 2013 at 19:10, Daniel James wrote:

...

It's a reasonable bet however that none of those core libraries has ever seen two major releases pass without a bug fix, so therefore those are moot.

There were no changes to MPL between Feb 21, 2011 and May 23, 2013, which is about 7 major releases.

I stand corrected. And quite surprised. Niall -- Currently unemployed and looking for work. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/

On 10/31/2013 07:21 PM, Niall Douglas wrote:

On 31 Oct 2013 at 19:00, Stephen Kelly wrote:

...

...

I am personally strongly in favour of libraries getting deprecated and removed from releases if they are not maintained - let's say no [snip] With 68 libraries in a circular-dependent mesh, how do you expect that would work? Judging from that dependency graph you posted a while ago, you're right there is a small core of libraries where deprecation due to lack of maintenance can't work.

I don't consider 68 out of 104 to be 'a small core'. Are you referring to the 11 packages that would remain interconnected after all of my suggestions were implemented? Some of my suggestions were implemented, but not all. I would agree with calling that small, but no further work on modularization is likely to be done. I'm not willing to do any such horizontal work after the move to git, so someone else would have to step up to do it. I also have not analysed the graph again since the proto->spirit edge removal, the property_map changes and Daniels commit to the migration map, so the 68 and 104 may not reflect todays state, and I don't know the effect that those changes in isolation had on the total graph.

I suspect that core library list is far smaller than 68, but you're the expert here. Do you know how tightly integrated those 68 libraries are e.g.

how many of them pull in a dependency only to never use it or use it very lightly?

I never counted, but 'at least some and maybe several'. Where I arbitrarily define some < several by an order of magnitude of 3 or so :).

How many pull in dependencies which can now be replaced with C++11 standard libraries instead? That sort of thing.

Probably less than 'some' above. I realise that that's meaningless without some quantified baseline :). Some users of the mpl are just using things like mpl::and_ and mpl::or_ etc, which can be implemented easily with a variadic template, thereby avoiding Boost.PP for example. Thanks, Steve.

On 31 Oct 2013 at 20:30, Stephen Kelly wrote:

Are you referring to the 11 packages that would remain interconnected after all of my suggestions were implemented? Some of my suggestions were implemented, but not all.

Yes I was. I obviously misunderstood, I thought that was going to happen eventually, or something close.

I would agree with calling that small, but no further work on modularization is likely to be done. I'm not willing to do any such horizontal work after the move to git, so someone else would have to step up to do it.

I think it was unfortunate that the git transition has got mixed up with modularisation. The two are quite different, but together they create a lot more change (and breakage) than either alone would.

...

how many of them pull in a dependency only to never use it or use it very lightly?

I never counted, but 'at least some and maybe several'. Where I arbitrarily define some < several by an order of magnitude of 3 or so :).

...

How many pull in dependencies which can now be replaced with C++11 standard libraries instead? That sort of thing.

Probably less than 'some' above. I realise that that's meaningless without some quantified baseline :).

Useful to know, and you know more here than most, even if it is just the shape of what is unknown. I suspect a libclang AST grokker could tell us the detailed truth here, but that's a lot of work to implement. I would say that removing libraries is an excellent way of discovering trivial dependencies, and increasing modularisation [cackle!]. Niall -- Currently unemployed and looking for work. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/

On Thursday 31 October 2013 12:20:03 Niall Douglas wrote:

On 31 Oct 2013 at 2:08, Ahmed Charles wrote:

...

I'm personally on the fence about this policy. I see some library authors that are responsive and reasonable with their library and I wouldn't want to disenfranchise them one bit. But I also see that it can create an 'old guard' sort of situation that benefits no one. With power should come responsibility and there should be a mechanism that ensures that libraries that stagnate are given new maintainers. I understand that there is a shortage of people signing up to maintain libraries, but I think at least part of that is due to the impression that libraries are only ever 'pried from the hands of their dead maintainers'.

I am personally strongly in favour of libraries getting deprecated and removed from releases if they are not maintained - let's say no bug fixes by its maintainer in two major release cycles adds them to the list of soon to be deprecated libraries, and no bug fixes by its maintainer in three major release cycles has them removed from Boost central and put into an attic. That encourages new maintainers to step forwards, and old maintainers to give up their control if they can't keep up due to life commitments.

It would require some political bravery from the SC though, as users will get upset. I would also personally count lack of adding direct C++11 support as equal to lack of bug fixing, but I appreciate that will be controversial (what is C++11 support anyway???) :)

I do not see a single good thing in such approach. Developers get frustrated because they are forced to do something even if they don't have resources for it. "Go fix bugs right now or we flush your work to drain" doesn't sound like an encouragement to me. Users get frustrated because the libraries they use disappear all of a sudden. And they may not be affected by the long standing bugs that no one fixes. Release managers are annoyed by having to watch if a given library has reached its "inactivity timeout".

AMDG On 10/31/2013 11:28 AM, Niall Douglas wrote:

...

Release managers are annoyed by having to watch if a given library has reached its "inactivity timeout".

This can be highly automated. A quick query of the issue tracker database will produce a useful shortlist. Automated emails could even be sent and another query to check if the maintainer does anything after an automated email.

No automated system can correctly distinguish between - serious bug - minor bug - user error - "yeah, it would be nice. I might get to it someday" - &c. In Christ, Steven Watanabe

On Thursday 31 October 2013 14:28:24 Niall Douglas wrote:

On 31 Oct 2013 at 22:13, Andrey Semashev wrote:

...

I do not see a single good thing in such approach. Developers get frustrated because they are forced to do something even if they don't have resources for it. "Go fix bugs right now or we flush your work to drain" doesn't sound like an encouragement to me.

No work gets flushed. It simply loses peer review approval and reenters sandbox, and therefore ceases to be an officially endorsed part of Boost. To reenter Boost, it can use the fast track peer review process rather than full peer review.

That basically means flushing. Do you know any major (or not) distribution that provides components from Boost sandbox? Do these components receive testing and review? Even if a library is unmaintained, it is still tested with the officially supported compilers, with the actual Boost and third party dependencies, if any. Should the breakage occur, it will eventually be fixed by some volunteer who probably uses the library and cares for it. That someone may not be prepared to become a maintainer, though.

...

Users get frustrated because the libraries they use disappear all of a sudden. And they may not be affected by the long standing bugs that no one fixes.

As a collection of libraries grows, eventually at some stage some pruning rules have to come into play. I wish we had more pruning in the ISO C++ standard for example, but hey it's hard enough adding things let alone removing them.

I see no need for that, at least not if Boost gets modularized.

...

Release managers are annoyed by having to watch if a given library has reached its "inactivity timeout".

This can be highly automated. A quick query of the issue tracker database will produce a useful shortlist. Automated emails could even be sent and another query to check if the maintainer does anything after an automated email.

I feel skeptical about such automated decision making systems. Anyway, I still don't see a single upside of this strategy. Rather than employing such a destructive approach, I'd suggest being more constructive and involved. If you have a favorite bug that you trip on every day for several years then go ahead and fix it. Suggest a patch and make it into Boost instead of slicing off the library and declare it a second class component. "Show me the code", as someone said [1]. [1] http://en.wikiquote.org/wiki/Linus_Torvalds

AMDG On 10/30/2013 06:07 AM, Ahmed Charles wrote:

Short of boost being forked by a group of energetic people interested in making massive changes, how exactly will it ever migrate to C++11/14 with the current ownership model where people have to contact ~100 library maintainers if they want to make changes across the entire project? If all I wanted to do was create a branch to work on C++11/14 work or anything like it, not only would it require touching ~100 git repos, I'd have to send ~100 emails and create ~100 trac tickets with patches and then manage ~100 different conversations with ~100 different people, across different countries, timezones, native languages, cultures, etc. How do you ever expect anyone to ever want to do that?

Your scenario is completely unrealistic in the first place. No one can make these kinds of sweeping changes in one shot without making serious errors. It simply isn't possible to understand all of boost at once at the level of detail needed to make major modifications correctly. In Christ, Steven Watanabe

Ahmed Charles wrote:

...

AMDG

On 10/30/2013 06:07 AM, Ahmed Charles wrote:

...

Short of boost being forked by a group of energetic people interested in making massive changes, how exactly will it ever migrate to C++11/14 with the current ownership model where people have to contact ~100 library maintainers if they want to make changes across the entire project? If all I wanted to do was create a branch to work on C++11/14 work or anything like it, not only would it require touching ~100 git repos, I'd have to send ~100 emails and create ~100 trac tickets with patches and then manage ~100 different conversations with ~100 different people, across different countries, timezones, native languages, cultures, etc. How do you ever expect anyone to ever want to do that?

Your scenario is completely unrealistic in the first place. No one can make these kinds of sweeping changes in one shot without making serious errors. It simply isn't possible to understand all of boost at once at the level of detail needed to make major modifications correctly.

Proving that something isn't possible is really hard. I didn't what the scope of the changes would be, ...

If you're doing any kind of serious work, the time investment per library will dwarf the effort of filing a ticket and sending an e-mail. For it not to do so, the work needs to be either superficial or heavily automated. Even then, to be sure that the massive changes haven't broken anything, you'd need to run the entire test suite after each round of changes. This wouldn't be any fun, either. It doesn't even matter. The process is not as inflexible as you think. Filing a ticket and notifying the maintainer is a matter of courtesy and respect, it's not a requirement. If you're good enough so that your changes are entirely beneficial, nobody will object. But that doesn't matter, either. The process is emergent from the structure of Boost in which maintainers are responsible for their libraries. This means that if your massive changes introduce bugs in some library, it will be the maintainer of that library who will have to deal with the bug reports. This naturally tends to make (active) maintainers somewhat protective. This all works fairly well in practice, if your measure working by the actual results. Stephen Kelly's situation is unique and one-off, because of the impending transition to Git. Normally, we'd do things in our old-fashioned, non-energetic, inflexible way across a few releases without entering the news.

Stephen Kelly wrote:

On 10/31/2013 01:54 PM, Peter Dimov wrote:

...

Normally, we'd do things in our old-fashioned, non-energetic, inflexible way across a few releases without entering the news.

Nothing entered the news in this case either.

By "without entering the news" I meant "without anyone being prompted to venture an opinion on how Boost's process is broken." (in other words, I referred to this thread.)

On 10/18/2013 07:04 PM, Edward Diener wrote:

On 10/18/2013 12:37 PM, Stephen Kelly wrote:

...

On 10/18/2013 06:28 PM, Edward Diener wrote:

...

On 10/18/2013 11:59 AM, Stephen Kelly wrote:

...

On 10/18/2013 05:42 PM, Edward Diener wrote:

...

The property_map library can be used completely outside of the graph library. What does moving parts of property_map into graph accomplish ?

It makes the property_map library/repo/package not depend on the graph library/repo/package.

The property_map library is a header only library. Please point out to me where in the property_map headers there is any reference to anything in the graph library.

Le-sigh.

I suggest you do your equivalent of this:

boost-trunk/boost/property_map{master}$ git grep boost/graph

I won't ruin the surprise for you by pasting the output.

If you don't understand my point after seeing the output, please just accept that you don't understand the point. No need to respond. A long sub-thread like this is bad.

No a sub-thread like this is not bad. When you feel entitled to do things without valid justification that is bad. And when you talk in condescending terms to others that is bad.

I was more coarse and insensitive than necessary in dealing with and responding to this subject. I want to apologise for that and I'll do my best to make sure it doesn't happen again. Thanks, Steve.

...

...

It makes the property_map library/repo/package not depend on the graph library/repo/package.

The property_map library is a header only library. Please point out to me where in the property_map headers there is any reference to anything in the graph library.

Le-sigh.

I suggest you do your equivalent of this:

boost-trunk/boost/property_map{master}$ git grep boost/graph

What makes you think Edward has a git repro around - most of us are still in SVN land.

I won't ruin the surprise for you by pasting the output.

If you don't understand my point after seeing the output, please just accept that you don't understand the point. No need to respond. A long sub-thread like this is bad.

Thanks for taking the thread off-track and into the human-round-trip zone,

Whatever your frustration, that's about the most singularly unhelpful answer I've seen in a while, Just saying your, John.

On 10/18/2013 3:26 PM, Jonathan Wakely wrote:

On 18 October 2013 18:14, John Maddock wrote:

...

...

I suggest you do your equivalent of this:

boost-trunk/boost/property_map{master}$ git grep boost/graph

What makes you think Edward has a git repro around - most of us are still in SVN land.

Me included, so my equivalent of Steve's command is "fgrep -R boost/graph boost/property_map" which took seconds and worked perfectly (with modern versions of subversion you don't get hits from the pristine text-base files, because there's only one .svn in the root dir, but even with older clients you can filter out the .svn matches.)

Although the delivery was unhelpful, the point remains that it's simple to check that property_map uses graph headers.

I did check but forgot to look into the parallel subdirectory.

On 10/18/2013 12:37 PM, Stephen Kelly wrote:

On 10/18/2013 06:28 PM, Edward Diener wrote:

...

On 10/18/2013 11:59 AM, Stephen Kelly wrote:

...

On 10/18/2013 05:42 PM, Edward Diener wrote:

...

The property_map library can be used completely outside of the graph library. What does moving parts of property_map into graph accomplish ?

It makes the property_map library/repo/package not depend on the graph library/repo/package.

The property_map library is a header only library. Please point out to me where in the property_map headers there is any reference to anything in the graph library.

Le-sigh.

I suggest you do your equivalent of this:

boost-trunk/boost/property_map{master}$ git grep boost/graph

I won't ruin the surprise for you by pasting the output.

If you don't understand my point after seeing the output, please just accept that you don't understand the point. No need to respond. A long sub-thread like this is bad.

Thanks for taking the thread off-track and into the human-round-trip zone,

I was in the wrong in that I had not looked at the 'parallel' directory of property_map in order to see that it does indeed have a dependency there on the graph library. Looking at the file 'distributed_property_map.hpp', where the dependency on graph exists, would it not be better to eventually move this and the specializations of distributed_property_map to the graph library so that property_map can then be independent of the graph library. I realize this is more than just moving a file, but rather involves moving the specializations of property map templates for the distributed property map out of their places in property_map to some place under graph. I also realize that this may be beyond what you have tasked yourself to do, but I would really like to see property_map as a library on its own independent of the graph library.

On 10/19/2013 3:31 AM, Stephen Kelly wrote:

On 10/19/2013 02:51 AM, Edward Diener wrote:

...

I realize this is more than just moving a file, but rather involves moving the specializations of property map templates for the distributed property map out of their places in property_map to some place under graph. I also realize that this may be beyond what you have tasked yourself to do,

It could be better and doesn't seem like unreasonable effort. If we ever get that far, I'd look into that, yes.

I am working on this and will post a message about the results when I am finished locally and have tested it.

On 10/19/2013 1:58 PM, Jeremiah Willcock wrote:

On Sat, 19 Oct 2013, Edward Diener wrote:

...

On 10/19/2013 3:31 AM, Stephen Kelly wrote:

...

On 10/19/2013 02:51 AM, Edward Diener wrote:

...

I realize this is more than just moving a file, but rather involves moving the specializations of property map templates for the distributed property map out of their places in property_map to some place under graph. I also realize that this may be beyond what you have tasked yourself to do,

It could be better and doesn't seem like unreasonable effort. If we ever get that far, I'd look into that, yes.

I am working on this and will post a message about the results when I am finished locally and have tested it.

Please keep me posted on that as well (and it would have been nice to have a subject line specifically on Graph and PropertyMap issues). I suspect that the underlying communication layer used by the parallel graph and property map libraries can be pulled out; it is in the graph library right now, leading to the dependency. There also seem to be more general utilities (untracked_pair and unsafe_serialize, for example) that might belong in Boost.Serialization instead of the graph or property map libraries. Looking through the other graph headers used in distributed_property_map.hpp (which is the one with the most dependencies), they can either be moved to boost/property_map/parallel since they have no other dependencies themselves, or (in the case of hash) moved into the graph library. I am also willing to make those changes if you want.

I did notice that you were the person who created the distributed_property_map.hpp, but I did not know what your e-mail address was so I did not try to contact you about it. My work has been to move distributed_property_map.hpp and .ipp into the graph/parallel directory and add into that directory a distributed_iterator_property_map.hpp and a distributed_vector_property_map.hpp taken from the property map specializations in property_map's property_map.hpp and vector_property_map.hpp, while removing the specilizations code from the latter two. Also the paths in graph tests would change to pickup these new locations. All this would effectively remove any dependency on graph from the property_map implementation. I am not changing any code whatsoever, just moving things around, and then I am going to run the property_map tests and graph tests to make sure I have not broken anything. I did not think to move any of the other files you mentioned into property_map itself from the graph library, as I was only considering the minimum way of achieving the separation. I do think that if one is specializing some class template in library A whose dependencies in the specialization code are in library B that the way to do this is to put the specializations in library B since an end-user of that particular specialization must "use" library B anyway to have the specialization work properly. Likewise I don't think that graph serialization code belongs in serialization but rather in graph. Any help you can give or advice is clearly welcomed, but I think I can get this done on my own without really having to understand, which of course you do since you wrote it, the distributed_property_map code and specializations based on it. My goal is purely to have property_map be not dependent on graph since it is its own concept. I have a use for property_map totally outside of any use for graph in a library I am still developing, thus my own willingness to do this work.

On 10/19/2013 3:06 PM, Jeremiah Willcock wrote:

On Sat, 19 Oct 2013, Edward Diener wrote:

...

On 10/19/2013 1:58 PM, Jeremiah Willcock wrote:

...

On Sat, 19 Oct 2013, Edward Diener wrote:

...

On 10/19/2013 3:31 AM, Stephen Kelly wrote:

...

On 10/19/2013 02:51 AM, Edward Diener wrote:

...

I realize this is more than just moving a file, but rather involves moving the specializations of property map templates for the distributed property map out of their places in property_map to some place under graph. I also realize that this may be beyond what you have tasked yourself to do,

It could be better and doesn't seem like unreasonable effort. If we ever get that far, I'd look into that, yes.

I am working on this and will post a message about the results when I am finished locally and have tested it.

Please keep me posted on that as well (and it would have been nice to have a subject line specifically on Graph and PropertyMap issues). I suspect that the underlying communication layer used by the parallel graph and property map libraries can be pulled out; it is in the graph library right now, leading to the dependency. There also seem to be more general utilities (untracked_pair and unsafe_serialize, for example) that might belong in Boost.Serialization instead of the graph or property map libraries. Looking through the other graph headers used in distributed_property_map.hpp (which is the one with the most dependencies), they can either be moved to boost/property_map/parallel since they have no other dependencies themselves, or (in the case of hash) moved into the graph library. I am also willing to make those changes if you want.

I did notice that you were the person who created the distributed_property_map.hpp, but I did not know what your e-mail address was so I did not try to contact you about it.

My work has been to move distributed_property_map.hpp and .ipp into the graph/parallel directory and add into that directory a distributed_iterator_property_map.hpp and a distributed_vector_property_map.hpp taken from the property map specializations in property_map's property_map.hpp and vector_property_map.hpp, while removing the specilizations code from the latter two. Also the paths in graph tests would change to pickup these new locations. All this would effectively remove any dependency on graph from the property_map implementation.

I am not changing any code whatsoever, just moving things around, and then I am going to run the property_map tests and graph tests to make sure I have not broken anything.

I did not think to move any of the other files you mentioned into property_map itself from the graph library, as I was only considering the minimum way of achieving the separation.

I had thought going the other way would be better: the files in Boost.Graph that property map code depends on don't themselves use much other graph code. Thus, they can be moved to Boost.PropertyMap without too much work, and that keeps all of the property map types that are there now in that library. There are other property map types (sequential and parallel) in Boost.Graph that should likely also be moved even though they don't need to be for dependency reasons.

If you do that it looks like you are then keeping a dependency for property_map on multi_index, serialization, and optional. I am not saying this is wrong if you feel that a distributed_property_map really should be part of property_map, since those addititional libraries are very useful for Boost libraries. I just wanted to point that out. Whereas the more normal non-distributed property map does not need to use those libraries AFAICS. Another option is to have distributed_property_map be a separate libray of its own. More work, obviously, but this would create a more minimal set of dependencies for property_map itself.

...

I do think that if one is specializing some class template in library A whose dependencies in the specialization code are in library B that the way to do this is to put the specializations in library B since an end-user of that particular specialization must "use" library B anyway to have the specialization work properly. Likewise I don't think that graph serialization code belongs in serialization but rather in graph.

The graph serialization doesn't, but there appear to be some utilities in there that are not specific to graphs and that might be useful for other Boost.Serialization or Boost.MPI users.

...

Any help you can give or advice is clearly welcomed, but I think I can get this done on my own without really having to understand, which of course you do since you wrote it, the distributed_property_map code and specializations based on it.

For the record, I didn't actually write it; I put it in and am maintaining it now.

Thanks for the information.

...

My goal is purely to have property_map be not dependent on graph since it is its own concept. I have a use for property_map totally outside of any use for graph in a library I am still developing, thus my own willingness to do this work.

I agree with your goal, but I think it makes more sense for distributed_property_map to be in PropertyMap rather than Graph (with its dependencies moved there as well).

If you feel that is the way it should be please go ahead and implement that change. My goal was to make property_map not dependent on graph.

On 10/19/2013 4:39 PM, Jeremiah Willcock wrote:

On Sat, 19 Oct 2013, Edward Diener wrote:

...

...

I had thought going the other way would be better: the files in Boost.Graph that property map code depends on don't themselves use much other graph code. Thus, they can be moved to Boost.PropertyMap without too much work, and that keeps all of the property map types that are there now in that library. There are other property map types (sequential and parallel) in Boost.Graph that should likely also be moved even though they don't need to be for dependency reasons.

If you do that it looks like you are then keeping a dependency for property_map on multi_index, serialization, and optional. I am not saying this is wrong if you feel that a distributed_property_map really should be part of property_map, since those addititional libraries are very useful for Boost libraries. I just wanted to point that out. Whereas the more normal non-distributed property map does not need to use those libraries AFAICS.

Another option is to have distributed_property_map be a separate libray of its own. More work, obviously, but this would create a more minimal set of dependencies for property_map itself.

A separate library might make more sense, actually. Another option would be for property_map/parallel to be treated as a separate library without being moved in the Boost tree.

I think that would be fine actaully. For that to work you will need to move the specializations of distributed_property_map from their places in property_map.hpp and vector_property_map.hpp to the property_map parallel directory as separate files with theier own names, as well as remove the header file inclusions for the parallel subdirectory in the otiginal files. I think that would satisfy the end-user who wanted to use property_map without having to drag in those dependencies for distributed_property_map. Also the distributed_property_map should probably then be documented as part of property_map rather than as part of graph, although graph could have the appropriate link to that documentation. Similarly tests for distrubuted_property_map should be part of that implementation rather than graph, and the correct header files referenced.

...

...

...

My goal is purely to have property_map be not dependent on graph since it is its own concept. I have a use for property_map totally outside of any use for graph in a library I am still developing, thus my own willingness to do this work.

I agree with your goal, but I think it makes more sense for distributed_property_map to be in PropertyMap rather than Graph (with its dependencies moved there as well).

If you feel that is the way it should be please go ahead and implement that change. My goal was to make property_map not dependent on graph.

That is what my proposed changes would accomplish as well, but they do not fix the multi_index, etc. dependencies you mention above.

On 10/21/2013 1:29 PM, Jeremiah Willcock wrote:

On Sat, 19 Oct 2013, Edward Diener wrote:

...

On 10/19/2013 4:39 PM, Jeremiah Willcock wrote:

...

On Sat, 19 Oct 2013, Edward Diener wrote:

...

...

I had thought going the other way would be better: the files in Boost.Graph that property map code depends on don't themselves use much other graph code. Thus, they can be moved to Boost.PropertyMap without too much work, and that keeps all of the property map types that are there now in that library. There are other property map types (sequential and parallel) in Boost.Graph that should likely also be moved even though they don't need to be for dependency reasons.

If you do that it looks like you are then keeping a dependency for property_map on multi_index, serialization, and optional. I am not saying this is wrong if you feel that a distributed_property_map really should be part of property_map, since those addititional libraries are very useful for Boost libraries. I just wanted to point that out. Whereas the more normal non-distributed property map does not need to use those libraries AFAICS.

Another option is to have distributed_property_map be a separate libray of its own. More work, obviously, but this would create a more minimal set of dependencies for property_map itself.

A separate library might make more sense, actually. Another option would be for property_map/parallel to be treated as a separate library without being moved in the Boost tree.

I think that would be fine actaully.

For that to work you will need to move the specializations of distributed_property_map from their places in property_map.hpp and vector_property_map.hpp to the property_map parallel directory as separate files with theier own names, as well as remove the header file inclusions for the parallel subdirectory in the otiginal files. I think that would satisfy the end-user who wanted to use property_map without having to drag in those dependencies for distributed_property_map.

Also the distributed_property_map should probably then be documented as part of property_map rather than as part of graph, although graph could have the appropriate link to that documentation.

Similarly tests for distrubuted_property_map should be part of that implementation rather than graph, and the correct header files referenced.

Right now, there is a #include from to a couple of files in the directory, conditioned on a macro being defined. Now that the parallel subdirectory will be treated as a separate library, this is likely to count as a dependency (which will be circular). Should I keep that in for compatibility?

The code in property_map.hpp starting with '#ifdef BOOST_GRAPH_USE_MPI' to the end of the #ifdef should all be moved to the parallel subdirectory IMO. It can be called, let's say, distributed_iterator_property_map.hpp and of course will '#include '. This moves the dependency out of property_map.hpp, so that end-users of the various property_map types are not bringing in the distributed property_map headers and code. Similarly in vector_property_map.hpp where the '#ifdef BOOST_GRAPH_USE_MPI' code can be moved to a file in the parallel subdirectory, called perhaps distributed_vector_property_map.hpp. The idea is that anyone using the various non-distributed property maps, which are the majority of property map usages, are not bringing in the distributed property map code and if an end-user wants a distributed property map version he needs to directly include the correct header file from the parallel directory. Doesn't this seem like the way it should work to you ?

On 10/21/2013 4:48 PM, Jeremiah Willcock wrote:

On Mon, 21 Oct 2013, Edward Diener wrote:

...

On 10/21/2013 1:29 PM, Jeremiah Willcock wrote:

...

On Sat, 19 Oct 2013, Edward Diener wrote:

...

On 10/19/2013 4:39 PM, Jeremiah Willcock wrote:

...

On Sat, 19 Oct 2013, Edward Diener wrote:

...

> I had thought going the other way would be better: the files in > Boost.Graph that property map code depends on don't themselves use > much > other graph code. Thus, they can be moved to Boost.PropertyMap > without > too much work, and that keeps all of the property map types that are > there now in that library. There are other property map types > (sequential and parallel) in Boost.Graph that should likely also be > moved even though they don't need to be for dependency reasons.

If you do that it looks like you are then keeping a dependency for property_map on multi_index, serialization, and optional. I am not saying this is wrong if you feel that a distributed_property_map really should be part of property_map, since those addititional libraries are very useful for Boost libraries. I just wanted to point that out. Whereas the more normal non-distributed property map does not need to use those libraries AFAICS.

Another option is to have distributed_property_map be a separate libray of its own. More work, obviously, but this would create a more minimal set of dependencies for property_map itself.

A separate library might make more sense, actually. Another option would be for property_map/parallel to be treated as a separate library without being moved in the Boost tree.

I think that would be fine actaully.

For that to work you will need to move the specializations of distributed_property_map from their places in property_map.hpp and vector_property_map.hpp to the property_map parallel directory as separate files with theier own names, as well as remove the header file inclusions for the parallel subdirectory in the otiginal files. I think that would satisfy the end-user who wanted to use property_map without having to drag in those dependencies for distributed_property_map.

Also the distributed_property_map should probably then be documented as part of property_map rather than as part of graph, although graph could have the appropriate link to that documentation.

Similarly tests for distrubuted_property_map should be part of that implementation rather than graph, and the correct header files referenced.

Right now, there is a #include from to a couple of files in the directory, conditioned on a macro being defined. Now that the parallel subdirectory will be treated as a separate library, this is likely to count as a dependency (which will be circular). Should I keep that in for compatibility?

The code in property_map.hpp starting with '#ifdef BOOST_GRAPH_USE_MPI' to the end of the #ifdef should all be moved to the parallel subdirectory IMO. It can be called, let's say, distributed_iterator_property_map.hpp and of course will '#include '. This moves the dependency out of property_map.hpp, so that end-users of the various property_map types are not bringing in the distributed property_map headers and code.

That is what I did, but left the #ifdef in with its body as just a #include for the version in .

...

Similarly in vector_property_map.hpp where the '#ifdef BOOST_GRAPH_USE_MPI' code can be moved to a file in the parallel subdirectory, called perhaps distributed_vector_property_map.hpp.

Same comment here.

...

The idea is that anyone using the various non-distributed property maps, which are the majority of property map usages, are not bringing in the distributed property map code and if an end-user wants a distributed property map version he needs to directly include the correct header file from the parallel directory.

Doesn't this seem like the way it should work to you ?

It is preferable in my opinion, but would break compatibility with old code that assumes that the sequential code pulls in the parallel code.

Yes, I agree it would. But I think it was a mistake to pull in the parallel code, with all of its dependencies, when just using the sequential property_map code. Even though you have reduced the dependencies of the parallel code by removing the dependency on the graph library there are still other dependencies which anyone using the sequential code should not have. This will be even more important in a modularized Boost system. The fix for breaking the old code is very easy, just including the correct header file from the parallel directory. If you want to make it even easier just create forwarding headers in the main property_map directory to bring in the needed headers in the parallel directory. A note for the 1.56 release can tell any users of the parallel code in property_map what to do in regards to their header file inclusion, and a message in the mailing list(s) can tell the same users who are using 'trunk' what to do.

On 10/21/2013 2:49 PM, Jeremiah Willcock wrote:

On Sat, 19 Oct 2013, Edward Diener wrote:

...

On 10/19/2013 4:39 PM, Jeremiah Willcock wrote:

...

On Sat, 19 Oct 2013, Edward Diener wrote:

...

...

I had thought going the other way would be better: the files in Boost.Graph that property map code depends on don't themselves use much other graph code. Thus, they can be moved to Boost.PropertyMap without too much work, and that keeps all of the property map types that are there now in that library. There are other property map types (sequential and parallel) in Boost.Graph that should likely also be moved even though they don't need to be for dependency reasons.

If you do that it looks like you are then keeping a dependency for property_map on multi_index, serialization, and optional. I am not saying this is wrong if you feel that a distributed_property_map really should be part of property_map, since those addititional libraries are very useful for Boost libraries. I just wanted to point that out. Whereas the more normal non-distributed property map does not need to use those libraries AFAICS.

Another option is to have distributed_property_map be a separate libray of its own. More work, obviously, but this would create a more minimal set of dependencies for property_map itself.

A separate library might make more sense, actually. Another option would be for property_map/parallel to be treated as a separate library without being moved in the Boost tree.

I think that would be fine actaully.

For that to work you will need to move the specializations of distributed_property_map from their places in property_map.hpp and vector_property_map.hpp to the property_map parallel directory as separate files with theier own names, as well as remove the header file inclusions for the parallel subdirectory in the otiginal files. I think that would satisfy the end-user who wanted to use property_map without having to drag in those dependencies for distributed_property_map.

Also the distributed_property_map should probably then be documented as part of property_map rather than as part of graph, although graph could have the appropriate link to that documentation.

Similarly tests for distrubuted_property_map should be part of that implementation rather than graph, and the correct header files referenced.

I have done the rearrangement of header files and namespaces, but not the tests, examples, or documentation yet. There are still likely circular dependencies because of the compatibility #includes I left in (see my other email about that).

See my response to the other e-mail. If you agree with it the tests just need to have some of the #includes change and of course the ones in graph now for distributed property maps should be moved to property_map instead. BTW thanks very much for working on all this. Your decision to keep distributed property maps in property_map is the right decision and the only reason I initially thought of moving the distributed property maps to graph was because I did not feel comfortable trying to figure out how to move the necessary graph support code into property_map.

On 10/18/2013 1:11 PM, John Maddock wrote:

...

...

...

The property_map library can be used completely outside of the graph library. What does moving parts of property_map into graph accomplish ?

It makes the property_map library/repo/package not depend on the graph library/repo/package.

The property_map library is a header only library. Please point out to me where in the property_map headers there is any reference to anything in the graph library.

In boost/property_map/parallel/distributed_property_map.hpp:

#include #include #include #include #include

Thanks, John.

On 10/25/2013 07:35 AM, Ahmed Charles wrote:

...

Date: Fri, 18 Oct 2013 00:24:57 +0200 From: steveire@gmail.com To: boost@lists.boost.org Subject: [boost] [modularization] Modularizing Boost (modularization)

* Phase 0 - remove dead weight by bumping compiler feature requirements * Phase 1 - move some files around so that the modularized repos form a mostly directed graph * Phase 2 - Form some kind of 'boost core library' or 'boost feature normalization library' from the guts of existing libraries like type_traits, static_assert, config mpl and utilities. * Phase 3 - Try to port the mpl to variadic templates so that the dependency on Boost.PP is not needed when variadic templates are available.

I'm still catching up on all of the replies, and I like the work overall and it seems to be going in the right direction.

Thanks for the detailed analysis.

One minor concern I have with the steps you outline below is that they seem to optimizing for reducing edges in the dependency graph rather than creating the right dependency structure, which is a subtle distinction.

Yes, they are distinct. Creating the right dependency structure is more what I had in mind as part of phase 2.

For example, moving the exception classes used by all of boost out of the exception library doesn't really seem like a win overall, since having files grouped logically is the entire point of a module.

I guess 'logically' might depend on point of view. BOOST_THROW_EXCEPTION might not throw an exception, depending on the capabilities of the compiler, among other things. So, from my point of view, it can be seen as 'feature normalization' and belong in some core location with other parts of boost which do 'normalization' of features of toolkits/compilers (think most of Config and static_assert, type_traits etc, and someday boost.any perhaps). The main reason I moved it out in my analysis was because the exception library also has other dependencies. Of course, another option would be to split it into two libraries to isolate those dependencies. Looking at the dependencies again now, even that may be unnecessary depending on what happens with the detail and utility repos.

I think the biggest question to ask is what libraries are expected to be at the core of boost and used by all other libraries and effectively create a layering structure, where libraries belong to layers and can only depend on libraries at it's level or below. The goal is to create as many levels as possible by moving libraries up in level whenever they have no more incoming links at their current level.

That's similar to what we are doing in KDE. The kdelibs libraries in KDE4 are very interdependent. http://quickgit.kde.org/?p=kdelibs.git&a=tree&hb=master 3 years ago I wrote "More interdependence between libraries is easier, but makes independent reuse much harder. We just have to find out if it's worth it." http://thread.gmane.org/gmane.comp.kde.devel.core/67458/focus=67520 and created a plan of 'tiers': http://techbase.kde.org/index.php?title=Projects/KDELibsModifications&oldid=55633 It took a lot of work and moving stuff around to 'clean up' kdelibs: http://community.kde.org/Frameworks/Epics/kdelibs_cleanups reduce duplication with Qt provisions (note that there is duplication of some classes/concepts between some boost libraries) : http://community.kde.org/Frameworks/Epics/Reduce_class_duplication and to do actual splitting: http://community.kde.org/Frameworks/Epics/Splitting_kdelibs Today we have four split out tiers and a staging directory (libraries not yet ready to be moved to a tier) to manage and layer dependencies: http://quickgit.kde.org/?p=kdelibs.git&a=tree&hb=frameworks and we'll soon be splitting that repo into multiple smaller git repos and making releases of modular 'KDE Frameworks 5'. Note that we are doing repo splitting after code modularization, in contrast to what boost is doing, and we'll use git grafts where we want the history from the unmodularized repo in the future. So, yes, what boost (should be) trying to do regarding modularization sounds familiar to me. There are indeed several lines of work to do with subtle or not-so subtle distinctions between them.

I also think the search should initially be focused on dependency links which make no sense, like proto -> spirit (I think that was the one Eric noticed) before moving on to dependencies which make sense but perhaps the files are in the wrong location.

Yes. I am not familiar enough with boost though to know what makes no sense. I would point anyone at the dot files I linked in my original mail if you want to find other edges which should be removed.

Lots of the changes below seem to be of the form "move utility code from library X to some library that is more heavily used than X and will therefore, reduce the graph". Is there a library that is core enough that it can be used by every other library and yet uses no other libraries? If that doesn't exist, should it?

It doesn't currently exist. I proposed creating it as part of phase 2.

...

There are now 653 edges and 68 nodes.

Next, move boost/detail/iterator.hpp and boost/iterator/iterator_traits.hpp to the type_traits library/repo:

Wouldn't it make more sense for iterator and iterator_traits to be in the iterator library? I can imagine moving lots of useful utilities to the 'detail' library simply cause that's what it's for, but the type_traits library shouldn't be used to contain iterator related code that has nothing to do with type_traits.

The motivation here is similar to what I wrote above about exceptions. Look at the dependencies of the iterator library in graph_all.dot to see how it contributes to the graph. Note also that boost/detail/iterator.hpp actually only contains traits helpers. So both files are about iterator traits. Moving them is appropriate in my point of view because they are related to traits, and because most users of those files do not need most of the iterator library or its dependencies.

This makes sense. Though it seems like you are suggesting that config is more widely used than detail, which seems strange given detail's goal as being the melting pot of various little things without a home. It's not obvious to me why moving something from one to the other really makes a big difference, but version code should be in a library that has no dependencies, like the library I suggested above.

Config also has no dependencies (as of https://svn.boost.org/trac/boost/changeset/85274 ) But you wrote and as I wrote in the OP, there may be sense in creating a core library/repo of which config is a part.

...

There are now 485 edges and 64 nodes. Several libraries form an inner mesh:

If we treat them as one element for now, we get a new graph from the rest

There are now 138 edges and 39 nodes

Move parts of {vector_,}property_map into graph_parallel:

This makes no sense to me, why would property_map code belong in the graph library? They seem to be solving completely different problems and my naive assumption would be that they have no dependencies on each other, though if that were the case, we probably wouldn't have a dependency graph that looks like spagetti. Anyways, perhaps you could explain this in more detail?

I think Edward and Jeremiah have made progress on this issue, though I admit I didn't follow the details closely, so I can't say more: http://thread.gmane.org/gmane.comp.lib.boost.devel/245078/focus=245276

Thanks again for doing all this research. It's definitely useful and in the right direction.

And thanks for the feedback! Steve.

On 10/25/2013 09:41 AM, Ahmed Charles wrote:

...

The main reason I moved it out in my analysis was because the exception library also has other dependencies. Of course, another option would be to split it into two libraries to isolate those dependencies. Looking at the dependencies again now, even that may be unnecessary depending on what happens with the detail and utility repos. I don't have the time to look right now, but I'd be curious why the exception library would have lots of dependencies and if it does, it would probably make sense to have it split into two, containing the basic functionality that every library needs and the advanced functionality that requires additional dependencies. For example, if you suggested a library called exception_core which contained the two headers above and everything using those exclusively depended on that library, I'd think it was perfect, because the files are logically placed and the dependency graph would be reduced to a usable state.

That could be an option. I initially wanted to move those files out of the exception library because exception brings the dependency on smart_ptr and tuple into the 'inner mesh' of (detail, utility,type_traits, smart_ptr, mpl, typeof) which I mentioned in my initial mail. Adding tuple to that might not matter as it brings in nothing not already in the mesh (just like smart_ptr as it turns out), if detail and utility can be arranged to not depend on stuff outside of the inner mesh. That's what I meant when I wrote 'Looking at the dependencies again now, even that may be unnecessary depending on what happens with the detail and utility repos.'. At least, I think discussion, moving or splitting of those exception files can be deferred or should be part of a 'boost core library' discussion. Thanks, Steve.

On 25 October 2013 06:35, Ahmed Charles wrote:

...

There are now 670 edges and 68 nodes.

Next, move boost/detail/workaround.hpp to the config library/repo:

This also makes sense, and it doesn't even have to move locations in the final layout (as mentioned in a follow up mail).

...

There are now 661 edges and 68 nodes.

Next, move boost/limits.hpp to the config library/repo:

This move makes sense.

That reminded me to create a pull request for moving 'workaround.hpp', 'limits.hpp', 'version.hpp' (also another minor change that I noticed). https://github.com/ryppl/Boost2Git/pull/45 If anyone objects, it's probably best to leave a comment on github.

On 11/01/2013 09:21 AM, Stephen Kelly wrote:

On 10/18/2013 12:24 AM, Stephen Kelly wrote:

...

If the dependencies between repositories are analysed, the result is

snip...

I'm still at a loss to reason with pushing forward with git migration instead of making these changes which have demonstrated edge removal, are valuable and are are easy cheap and quick.

Please give some short references or explanation about what you expect to become harder to do after the migration. I guess if migration plans are to be reconsidered there may need to be a clear understanding why the added work or complexity you are implying is worth waiting for. You should probably propose a new date for git migration with a viable rationale. Just saying you don't understand why migration is not on hold is not really fair. Personally I am thinking you have started an important and large task. But it is not clear when you will be satisfied. In the meantime someone else may show up with additional work that need to be done prior to migration, with tools they know rather than tools they don't know yet. -- Bjørn

On 11/01/2013 10:37 AM, Stephen Kelly wrote:

On 11/01/2013 10:10 AM, Bjørn Roald wrote:

...

On 11/01/2013 09:21 AM, Stephen Kelly wrote:

...

On 10/18/2013 12:24 AM, Stephen Kelly wrote:

...

If the dependencies between repositories are analysed, the result is

snip...

...

I'm still at a loss to reason with pushing forward with git migration instead of making these changes which have demonstrated edge removal, are valuable and are are easy cheap and quick.

Please give some short references or explanation about what you expect to become harder to do after the migration.

Working with git submodules adds layers of 'hardness'.

'git grep' does not pierce submodules for one thing. A lightweight ad-hoc use of it becomes a heavier script full of necessary tricks such as adding '|| true' and quoting problems.

Yes, it is a messy to deal with other than the simplest submodule foreach commands, in particular it get very messy when some dynamic input data is needed. Since submodule foreach is to tricky, lack of submodule awareness in some of the git commands is very annoying. The natural support feature for submodule grep would be something like git grep --recursive <pattern> But that is not supported. There is some talk about it here: http://lists-archives.com/git/729379-submodule-aware-grep.html but that was 3 years ago, and as far as I can tell this has not been added in any way to git, so I think we need to figure ways to get around without it and similar support in other some other git commands. I tried the git-grep-submodule wrapper command from one of the suggested patches in the above cited discussion, and I combined it with a simple alias in my ~/.gitconfig file. [alias] rgrep = "!f() { git grep $*; git grep-submodule $*;}; f" The git-grep-submodule script need to be somewhere in your executable PATH and have executable bit set. Then I can type: git grep -n <pattern> git grep-submodule -n <pattern> or simply git rgrep -n <pattern> to get both supermodule and submodule grep working This works for me, so maybe it may be worth trying when you need to work with git submodules. A problem is that these commands are not standard, so they will create problems when referenced in mailing lists etc. Maybe boost should have git related utilities like this shared in some tools repository.

For example, to acquire the numbers I pasted here:

http://thread.gmane.org/gmane.comp.lib.boost.devel/245078/focus=245123

I first tried to get the answer from the modularized repos.

While I can do this:

git log --oneline --author=steveire | read; echo $?'

I could find no way of wrapping that in a git submodule foreach.

I see, I tried to make sense of why this works so poorly in git submodule foreach. I was struggling with it for a while and gave up. My limited shell voodoo does not grok this. I suspect the use of the /read/ builtin command play games with me. Maybe it is not the bash version of /read/ that get invoked, or something else is the problem. I learned enough from trying to wrap your git log command to try an alternate approach that works for me. To get number of commits per author per module, I defined a bash function in a file submodule_tools.sh: commit_count_by_author(){ if [ -z "$1" ] ; then echo -e "Missing <author> argument, email matching regex"; return 1; fi export foo="git log --oneline --no-merges --author=$1"; echo `basename $(pwd)` `$foo | wc -l`; git submodule foreach --quiet 'echo $name `$foo | wc -l`'; }; Notes on commit_count_by_author utility: 1. The export of /foo/ is needed to make it visible inside the single quoted command for submodule foreach which. Submodule foreach does not like having the command double quoted. In general the environment in the foreach command is very limited :-( and passing data and commands inn there is tricky, I was not able to pass the pipe as part of the $foo variable without messing up the interpretation of the command tokens which are all manged. I was not able to get $@ to work to keep command tokens separated and thus make this simple hack into a more general utility :-( 2. The /author/ parameter is a regex pattern used to match the email address that is recorded along with each commit, Use the full address or at least append the @ character to prevent accidental match with multiple authors. I was not able to successfully use ^ and $ to limit the regex to force exact match, I don't know why, but it is probably due to missing quoting, escaping, or what not. To list all modules with number of commits by Beman Dawes, where merge commits are not counted, source and call the utility: . tools/git/submodule_tools.sh commit_count_by_author bdawes@ modular-boost 1696 accumulators 0 algorithm 7 any 13 array 24 asio 5 assign 3 atomic 0 bimap 3 bind 5 ... To strip off modules with no commits, and the count: commit_count_by_author bdawes@ | grep -v " 0$" | cut -d ' ' -f 1 which is similar to your use case I think. The notes above may explain some of the problems with the naive foreach wrapping I tried first. Hopefully the notes and example may help in other cases. But the best thing would be to find a simpler, more robust and general way to wrap recursive commands for submodules.

Git submodules make horizontal work (ie, the kind of work that I've been doing) harder.

I agree, we need to find ways to make it less so. The basic work flow become complicated when working horizontally across submodules with dependencies between the changes. If somebody know how other projects deal with this, it would be good to know. Here is how I see it, I assume here that a hot-fix branch named equally for each module is the way to go: * You need to take extra care to check out local hot-fix branch for each repository you start working on. * When done with changes, commit and push the hot-fix branches to some sensible public place. This is not as straight forward as we could want it to be, although similar to other library contributions. It need to be done for each module you touch. * Create pull requests as needed. * Someone need to pull the hot-fix' branches into each of the official GitHub repositories, slow response here will block progress. * Merging to master too early in one module may block other merges in that module, so that may not make sense. * The release managers need to be made aware of any dependencies between develop branch commits across modules. * How is it tested? * I guess at some point it all need to be controlled by release managers for all affected libraries, i.e.: the release managers merge to master branch in some synchronized fashion. People with special administrative roles need to get involved when such commits need to be synchronized across multiple modules. I assume we cannot expect the individual authors to respond to pull requests in a timely way in these cases. Maybe some other branching and pulling scheme could help. Any thoughts.

...

I guess if migration plans are to be reconsidered there may need to be a clear understanding why the added work or complexity you are implying is worth waiting for.

This mail is just an explanation to your query, not asking for reconsideration.

Thanks for your reply and clarifications. -- Bjørn

On 11/03/2013 08:40 PM, Stephen Kelly wrote:

On 11/03/2013 08:01 PM, Bjørn Roald wrote: snip...

...

I tried the git-grep-submodule wrapper command from one of the suggested patches in the above cited discussion, and I combined it with a simple alias in my ~/.gitconfig file.

[alias] rgrep = "!f() { git grep $*; git grep-submodule $*;}; f"

It is good that the result from each submodule is not paged individually (git grep-submodule handles that). However, the above results in two result sets paged individually. I tried to find a way to fix that but it seems git_pager can't be used in an alias.

GIT_PAGER=cat git rgrep MODULAR works for me. -- Bjørn

Stephen Kelly wrote:

The 'new' flyweight dependency on smart_ptr was actually already pre-existing, but my script missed it before. Similar is true for the function and multi_index dependencies on smart_ptr:

flyweight/refcounted.hpp:#include flyweight/detail/recursive_lw_mutex.hpp:#include function/function_base.hpp:#include multi_index/detail/safe_mode.hpp:#include

Including detail headers from another library is a code-smell. Something is might be wrong.

atomic_count, lightweight_mutex, sp_typeinfo are all components that I've written in the course of writing and maintaining SmartPtr, but they are useful on their own and do not depend on anything (which is why they're included from detail/ and not smart_ptr/detail, which would indeed be a cause of concern.) lightweight_mutex, for example, is a mutex that is header-only, whereas using the Boost.Threads mutex would introduce a dependency on the compiled library (and who knows what else.) sp_typeinfo is a type_info wrapper that works when RTTI is off. Just moving these headers somewhere else will break the module-level dependency to SmartPtr but will introduce a module-level dependency to SomewhereElse, and I doubt that this will be an improvement. In addition, I'll then have to co-maintain SomewhereElse.

Stephen Kelly wrote:

My gut tells me it would be an improvement.

Your gut is wrong, although I'm not surprised one bit by your assumption that I'm careless about dependencies. It's very much in line with your general behavior so far. These are the dependencies of SmartPtr at the moment according to nov1_strong.dot: smart_ptr -> exception smart_ptr -> type_traits smart_ptr -> detail smart_ptr -> utility ->exception is unavoidable because of throw_exception. ->detail is detail/interlocked.hpp (self-contained header), which I'll kill by making a local copy. ->utility is utility/addressof.hpp (another self-contained header), which I will likewise deal with. ->type_traits is something I reluctantly accepted when I added make_shared, because it needs aligned storage. It brings in -> mpl -> pp, which I hate, but at that point it was dawning on me that striving to minimize dependencies in the current structure is a lost cause. I'll probably need to do a local copy of type_with_alignment and alignment_of too, but that's not going to be easy. The best candidate for moving these headers into is utility: utility -> exception utility -> type_traits utility -> mpl utility -> iterator which, as you can see, has more dependencies of smart_ptr even now, because iterator -> function_types iterator -> conversion iterator -> tuple iterator -> mpl iterator -> detail iterator -> type_traits iterator -> concept_check iterator -> smart_ptr iterator -> optional iterator -> utility It even depends on smart_ptr. _If_ we had a "utility" module that was absolutely required to not depend on anything besides Config, moving such self-contained headers there would be an improvement. We don't.

->exception is unavoidable because of throw_exception. ->detail is detail/interlocked.hpp (self-contained header), which I'll kill by making a local copy. ->utility is utility/addressof.hpp (another self-contained header), which I will likewise deal with.

Oh, please don't start making copies of things just to please a dependency analyzer - there should be "one true copy" of each file, spawning multiple copies all over the shop is just insane. If there are self contained headers in some/many core libraries, then we should use a tool that is smart enough to detect that and behave sensibly. Otherwise move these self-contained details into some sort of "core" module that depends on nothing but config. Just my 2c, John.

John Maddock wrote:

...

If there are self contained headers in some/many core libraries, then we should use a tool that is smart enough to detect that and behave sensibly. Otherwise move these self-contained details into some sort of "core" module that depends on nothing but config.

That's basically what I suggested as an alternative, some kind of a Utility module that is absolutely not allowed to depend on anything but Config.

How hard is it to create such a library and who would have to buy off on it? It's not like it needs a review given that it's meant for code that's already in boost to be moved into it, just like 'detail' never got a review (I assume).

On 11/01/2013 06:00 PM, John Maddock wrote:

...

->exception is unavoidable because of throw_exception. ->detail is detail/interlocked.hpp (self-contained header), which I'll kill by making a local copy. ->utility is utility/addressof.hpp (another self-contained header), which I will likewise deal with.

Oh, please don't start making copies of things just to please a dependency analyzer - there should be "one true copy" of each file, spawning multiple copies all over the shop is just insane.

I agree. The right solution is not copies. Thanks, Steve.

->type_traits is something I reluctantly accepted when I added make_shared, because it needs aligned storage. It brings in -> mpl -> pp, which I hate, but at that point it was dawning on me that striving to minimize dependencies in the current structure is a lost cause. I'll probably need to do a local copy of type_with_alignment and alignment_of too, but that's not going to be easy.

I can't help but wonder if type_traits could be reimplemented in C++11 without any dependencies at all (and still interoperate correctly with MPL etc). Certainly now that compiler requirements have been bumped up, I suspect there's a bunch of stuff in there that could be removed. Probably. Maybe. I don't really know for sure, and I'm certainly not convinced it's worth the effort... John.

On 11/01/2013 06:33 PM, Peter Dimov wrote:

But it doesn't make any sense to do this now. It's almost 2014.

Can you explain the connection between these two sentences? The first c++14 capable compiler on the market (assuming that's the reference you are making) does not change anything until it is the minimum requirement for boost. Thanks, Steve.

On 11/04/2013 12:35 PM, Peter Dimov wrote:

My point was that Boost components that have been accepted into the standard are already obsolete

I see. I don't agree with this (and that's ok!). Those components only become obsolete when 1) the minimum compiler and toolchain requirements of boost are increased to be able to rely on the std versions. 2) the boost code is ported to the std versions. Thanks, Steve.

A while back there was a discussion in my team whether (now that the current release of applications are being built in a C++11 compiler) the code should continue to use boost::shared_ptr as before, or mix in std::shared_ptr in newer code, or do a global search-n-replace. (And similarly for some of the threading stuff.)

Mixing was quickly ruled out as too confusing and painful (due to incompatibilities). And we eventually decided not to search-n-replace because (a) the two implementations are not entirely identical, so this might introduce bugs; (b) continuing to use the Boost version makes it easier to backport changes to older releases that still use C++98 compilers; (c) presumably the Boost version would be bugfixed or feature-enhanced in advance of the std version, or internally fall back to

Gavin Lambert wrote: the std version where compatible.

Do you think that some of those assumptions are flawed?

Not flawed, but they may not be entirely correct either. (b) isn't much of an argument since you can always do namespace std { using boost::shared_ptr; }. In shared_ptr's case, (c) is true in that boost::shared_ptr is not (yet) in std, but that's probably an exception as many (most?) such libraries are in maintenance-only mode and may even fall behind the std versions. If you can eliminate the dependency to Boost completely by using the standard library, it probably would make sense to do so; otherwise, whether to use boost::shared_ptr or std::shared_ptr is a coin toss. Both (ought to) work.

Le 05/11/13 13:50, Klaim - Joël Lamotte a écrit :

On Tue, Nov 5, 2013 at 7:42 AM, Gavin Lambert wrote:

...

Do you think that some of those assumptions are flawed?

Another example is in MSVC11 (and I assume is still in MSVC12) there is a minor bug in std::chrono which makes it impractical to use in code that needs high precision of time. This forced me to use boost::chrono, which forced me to use boost::thread instead of std::thread because the time-related interface aren't compatible and require tons of casting. Andrey Semashev is working on this sens, to allow std::chrono interface and other in Boost.Sync, but I don't know if/when this could be usable in Boost.Thread. Having alternative implementations of the standard, in particular when it's mostly the same code whatever the target plateform, is a good thing.

Recently, I have added a internal name space csbl Common Std Boost Lib, that allows to use either std or boost for some classes (See boost/thread/csbl in trunk). While doing some of the adaptations, I find some problems: 1. specialization of templates in std or boost must be explicitly done on std or boost not on csbl :( 2. any function used any boost class in the interface can not be changed to use csbl without breaking the interface. I would like to know what other have already done to try to use std or boost conditionally. Best, Vicente

On 5 Nov 2013 at 18:57, Vicente J. Botet Escriba wrote:

I would like to know what other have already done to try to use std or boost conditionally.

AFIO uses a thin compile-time thunk layer to auto select between Boost and C++11 STL implementations for atomic, mutex and chrono (AFIO currently *always* uses Boost.Thread - thanks to your enhancements Vicente). You can see it in action at https://github.com/BoostGSoC/boost.afio/blob/master/boost/afio/detail/ std_atomic_mutex_chrono.hpp. Niall -- Currently unemployed and looking for work. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/