On 4 June 2015 at 22:06, Peter Dimov
It doesn't matter where the modules are. It matters where the libraries are. To determine that, you walk the filesystem. It's much simpler if the directory structure is regular and libraries are libs/*. So for example you want to find all headers - you look at libs/*/include. You want to build all libraries that require building - you look for libs/*/build/Jamfile*. You want to test all libraries - you look for libs/*/test/Jamfile*. You want the failure markup - you look for libs/*/test/failure-markup.xml. You want the changelog - you look for libs/*/doc/changes.xml (or whatever).
The first two already work, although they do need to account for a few special cases.
Multiple people have mentioned the need for nested libraries. I think they need to be supported.
I can't think of a use case that would need to be concerned with where the Git modules are, or with whether there are Git modules at all.
The commit bot I wrote obviously has to use them, some of my other tools pull data from bare repositories so that I can quickly deal with different branches, a build tool might need to deal with them if it wants to do something like link to the module's current version. My original post was a reply to a comment about the difficulty of dealing with git modules. If you're not concerned with git modules, why did you reply to it?