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. 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).
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.
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. 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. The current report is more stable. You can change includes within the same module without affecting it, and you can include another header from the same module without affecting it. One can argue that it's not "correct", but it's more useful. My module is on level 7, can I use this? It's on level 4, so it'd probably not be much of a problem. That other thing? It's on 9, so perhaps not.