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 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.