On 06/15/2014 02:30 PM, Andrey Semashev wrote:
On Sunday 15 June 2014 13:49:20 Vicente J. Botet Escriba wrote:
Le 15/06/14 13:40, Andrey Semashev a écrit :
On Sunday 15 June 2014 13:26:52 Vicente J. Botet Escriba wrote:
Le 15/06/14 12:48, Andrey Semashev a écrit :
On Sunday 15 June 2014 12:13:08 Vicente J. Botet Escriba wrote:
Le 14/06/14 18:34, Stephen Kelly a écrit : > Vicente J. Botet Escriba wrote: Yes, and I propose to create a date_time.serialization submodule that breaks the date_time -> serialization dependency.
date_time.serialization -> date_time serialization
The approach of extracting glue headers to separate submodules is not scalable. We have many other libraries using the same approach to optional dependencies.
Why?
Because it creates lots of tiny submodules, which creates maintainability and usability problems.
Why?
What you mean why? Submodules are a constant pain to deal with. They don't allow the complete history of the library, they don't allow synchronized operations on them (e.g. do changes to multiple submodules in a single commit/push), adding or removing them requires privileges. In Log I have at least 6 glue headers, I don't want to deal with 7 different repos if they are extracted.
I is now clear to me that you are thinking about git submodules, not the mechanism supported by tools/boostdep which simply look for a sublibs file, and if it exsist, it will look in subdirectories for */include/boost and if found treat it as a sub-module. Boost.build already support this and it is in use in: $ find libs -name 'sublibs' libs/geometry/sublibs libs/spirit/sublibs libs/algorithm/sublibs libs/functional/sublibs libs/utility/sublibs libs/numeric/sublibs
I don't see why I would depend on Serialization if I don't use it even if I use DateTime. IMHO, it is up to the client of the serialization of the DateTime types to use the DateTime.Serialization sub-module.
You are right to desire not depending on Serialization if you don't use it. But this should not be achieved with submodules, IMHO.
I'm open to discuss any alternative solving the issue.
I think there was a proposal not long ago to track dependencies based on headers, pretty much like boostdep does. Then we only need to mark the optional headers in some metadata files and there you go.
+1 That could work, but some concrete solution is needed. However, if you reconsider how much that differ from the solution above, maybe that is good enough? -- Bjørn