Vicente Botet wrote
Hi all,
After the long threads concerning the modularization it seems clear to me that we are in an impasse.
I agree with this. It just takes more work. I would like to broaden the discussion a little. I was looking searching for John Lakos' email address in order to ask him to offer his insights into the discussion. I'm not able to find it (of course, thanks spammers) but surely someone here knows how to send him such an invitation. John attended BoostCon and CPPCon as a speaker and has writing the canonical reference on this subject. Growing Boost to 500 libraries would likely be the largest challenge ever to ideas about how to organized large, de-coupled libraries of code. I've looking around a little. and found: https://github.com/bloomberg/bde/wiki/Physical-Code-Organization which is a little helpful. I believe that we're having difficulties because we haven't stepped back enough. To lot's of people it's a simple matter - elimination cycles, simplifying dependency graphs, etc. But I think it's bigger than that. I think it will impact Boost coding standards, our deployment our testing model, deprecation, library overlap, and who knows what else. These kinds of changes are always disruptive and I would like to spend a little extra effort to try to get this closer to being right. Robert Ramey -- View this message in context: http://boost.2283326.n4.nabble.com/modularization-What-is-a-module-What-is-a... Sent from the Boost - Dev mailing list archive at Nabble.com.