Le 15/06/14 15:07, Andrey Semashev a écrit :
On Sunday 15 June 2014 15:44:49 Peter Dimov wrote:
Andrey Semashev wrote:
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 understood Vicente to mean a sub-sub-module. When I read this:
Yes, and I propose to create a date_time.serialization submodule that breaks the date_time -> serialization dependency. I got the idea that Vicente meant the full fledged git submodule, with its own repository. If we're talking about just structural changes within the same submodule then the perspective changes.
I requested on this list what was the criteria for associating a file to a module(sub-module) and Peter gave me the criteria. I'm just using it.
These don't have their own repos. They are a subdirectory in an existing repo, and have the directory structure of a module.
date_time/ include/ src/ test/ serialization/ include/ src/ test/
boostdep will show this as date_time~serialization (like numeric~conversion). Yes, this approach looks more interesting.
Sorry if I was not clear enough. I have already extracted Stopwatches from Chrono in this way.
Tracking headers instead of modules has its own disadvantages. The module levels report, for example, would no longer make sense, as parts of the same module would need to be at level 0 and other parts at level 11. Yes, although I don't really understand what a level means. It surely doesn't correspond to the number of dependencies, although there is some correlation. When deciding whether to use a library in my library I will be looking at its dependencies, not some level index.
See my comment on level on the other post. Vicente