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.
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.
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.
In addition, if you include the right header of module X you'd be fine, and if you include the wrong header, you'll bring in the world. In another addition, if the right header of X is changed to include a wrong header from X, you'll suddenly start depending on the world.
True. Although you're not saved from changes when you build dependency graph based on submodules. I'd say, you're more vulnerable to dependency creep in case of submodules than headers. I guess, it all comes down to how we're going to use this dependency information. If our packaging/deploying tool is based on submodules then we should follow that line. In this case I would prefer that your above sub-sub- module approach is taken as a baseline; breeding repositories is not the way to go, IMHO. If the tool is header based then the submodules are just a convention to separate libraries, grant privileges and that's about it.