Le 15/06/14 14:44, Peter Dimov a écrit :
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).
Yes this is exactly what I'm proposing.
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.
Optional headers should be associated to a sub-module as this reduce the dependencies. This is not hard to do. A different case is a file D.hpp that includes conditionally (preprocessor) another file B.hpp. IMO, this makes D depend on B until we don't include a context for the dependency relationship. This context could include a platform, a compiler, a standard library and also the defines that the user includes on its user.hpp file.
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.
I agree completely here with Peter. Tracking this level information is very useful. I would add that new dependencies on library at level 7 should be possible but that would need reflexion and IMO should be posted on this list. Once we reach to have a strict ordering we should preserve it. This doesn't mean that a library can not change of levels, but the changes must not add cycles. Best, Vicente