On 05/30/2014 01:17 PM, John Maddock wrote:
On 30/05/2014 10:44, Andrey Semashev wrote:
On Thursday 29 May 2014 22:22:05 Julian Gonggrijp wrote:
PROPOSAL
The following (evolutionary) global changes to Boost should be planned and given priority over any other proposals [e.g. 5], in the following order:
1. Reduction of dependencies between Boost libraries.
This is a worthy goal, I don't think anyone reasonably disagrees with this.
+1
Agree, to a reasonable point. I don't think that solid libraries should be torn apart or unrelated components of different libraries should be mixed together just to reduce dependencies. The cases where this would be beneficial should be discussed with library maintainers.
I think that notion of optional dependencies it also needed to achieve this goal. There are multiple places in Boost where dependencies are intentionally loosened but formally exist.
Right the devil is in the detail.
For example the Math lib is one of those with cyclic dependencies - there's a small core that a few libraries depend on, but which Math also uses to some degree (like lexical_cast).
The question is:
* How many sub libraries does it need to be split into? FP classification is one, constants another, possibly rounding functions one more, then one more for everything else. Grief.
I am not sure the Grief need to be so bad. Are you assuming all modules have to be maintained in separate Git repositories? That does not have to be the case. I will try to explain better, i.e. with other words, what I have tried to say in past discussion on this topic. I will use Boost.Math as an example, but this applies to any Boost Library, maybe in particular to Config which configure dependencies to a large number of technology dependent supporting features. Those features can be seen as modules as well of you follow my line of though. So, let us say Math repository is *not* split in any way but continue more or less as is, but is modularized somehow. What could that look like: First of all, everything that is supporting to the library itself such as tests, examples, docs, etc. are defined as separate modules. I think these already live in their separate sub-directories and have their separate build mechanics. None of this incur dependencies in the Math Library modules themselves. Then, everything in the library itself is split into modules based on some analysis of dependencies and re-engineering deemed needed to reduce those dependencies. The source and headers does not necessarily need to be moved around to make it explicit in the file structure of the repository. That could be at the discretion of library maintainers. However, the library maintainer need to support some means for external tools to identify the content of the modules and their direct dependencies. Such tools could then support various packaging and deployment needs. The granularity of modules may vary a-lot. Not accepting that will create problems. As example, there is some talk of optional headers in this discussion, in my mind that is simply a separate module. It is no need to require such single header modules to be moved into their own library, or to attempt to collect such headers with related dependencies into some common module. That is just turning the problem around, mot really solving anything. To understand where modularizing is going, and thus be able to answer the poll with less ambiguities. I think some fundamentals need to be agreed. Some issues in that regard is at least unclear to me, or I expect there to be other views than mine on the list if we where asked questions, like for example: - What is a module? - What is the relationship between modules and libraries? - What is the relationship between modules and source repositories? - When does a dependency between two modules occur? - What sort of dependencies do we want to prevent occurring? Intentions of those willing to proceed with work on modularizing boost is not clearly stated. References to past discussions are given, but no conclusions about how to proceed. I think that is intentional as some of the process may best be agreed to later. However there is a danger of starting off in the wrong direction. So maybe we should try to agree on some ground rules for modules in boost. Below are my current notions of how the above questions should be answered. I expect other to have other views. ----------- What is a module? ------------- A module can be a single file or a collection of files (e.g.: header and source files) that are hard or impossible to use without the rest of the module. A module is self contained, except that it may have defined dependencies to other modules incurring when it is used by a given tool-set. ---- What is the relationship between modules and libraries? ----- A library has a maintainer individual or group and is maintained in a separate repository from other libraries in Boost. A library may contain many modules. ---- What is the relationship between modules and repositories? ----- Repositories are used to maintain configuration control of a library or some other set of modules in boost. A repository may contain many modules. ---- When does a dependency between two modules occur? ----- The dependency occur when a certain tool processing the dependent module uses or is attempting to use the module it is depending upon. In the latter case we have a failure, which we clearly want to prevent, if that is not feasible, then failures should at least be simple to resolve by identifying the dependency and get it properly deployed onto the system. ---- What sort of dependencies do we want to prevent occurring? ---- Dependencies to modules providing features the user is not requiring. Dependencies to modules using technology the user is not utilizing. -- Bjørn