Subject: Re: [boost] What would make tool authors happier..
From: Daniel James (dnljms_at_[hidden])
Date: 2015-06-04 18:30:00
On 4 June 2015 at 22:06, Peter Dimov <lists_at_[hidden]> wrote:
>
> 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?