On Mon, Jan 4, 2016 at 12:46 PM, Louis Dionne
Dear list,
Currently, all Boost libraries are required to have a meta/libraries.json file at their root, which contains some meta-data describing the library. As I understand it, this meta-data is then used to generate the list of all
libraries with their description when a release is done.
That's one use.
I find having such a directory at the root of every library annoying, since it clutters it. Furthermore, for metaprogramming libraries, the name can be slightly confusing since meta/ might be expected to contain something different.
1. I don't see how it can be confusing to have that dir. 2. Having other dirs other than the required ones would not be common. And not something I would recommend. 3. The contents of the meta dir are not restricted to Boost. The information in it could be used more generally. 4. We are likely going to add more data files to that dir for other uses. For example it would be convenient to add release notes data in there. I propose that we allow libraries to specify their metadata in a `.boost`
file located at their root. Using a dotfile is the most common way of providing information for an external service (for example .travis.yml), and dotfiles are usually more discrete when viewing the project in an editor. Furthermore, making `boost` part of the filename is more descriptive.
I don't see the point. It's a Boost library. It's already has "Boost" in the "name".
I have submitted a pull request to BPM [1] adding the ability to fetch the meta data in a .boost file. The meta-data can still be provided in meta/libraries.json, so this should not affect existing libraries.
It would as it's more maintenance and confusion as to where to have that data. And as was pointed out that's not the only consumer of that data.
Related questions that we might want to consider:
- Should it be .boost.json instead of .boost?
Meh. - Perhaps we could store the meta-data for all the libraries in the same
place, and get rid of the individual meta-data files?
No. The point of having that dir in each library is to decentralize the information so that it can be easily managed by the individual authors instead of needing continual release manager intervention.
- If this suggestion is accepted, is there more to modify than BPM?
Yes. There are other tools (website & release related) . And of course documentation. In summary, I'm against this as the perceived benefit is minimal compared to the "implementation effort". -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail