Daniel James wrote:
On 4 June 2015 at 21:30, Peter Dimov
wrote: Daniel James wrote:
On 4 June 2015 at 19:56, Peter Dimov
wrote: ...
Walking the filesystem produces better results in the following cases:
- when you have manually placed a (proposed) library in libs/ that is not yet a submodule - when you have a Boost directory structure that has no Git metadata
In these cases, why does your tool need to understand git modules?
It doesn't.
So why does it matter where the modules are?
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. 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.