Re: [boost] Library list generated from meta/libraries.json files

Daniel James wrote:

On 5 January 2015 at 14:10, Peter Dimov wrote:

...

I've put a library list generated from the meta/libraries.json files, at:

http://www.pdimov.com/tmp/boost/index.html

We're already dealing with this on the website, this is how the documentation list is generated. The full data is at:

http://www.boost.org/doc/libraries.xml

Which was set up by Rene years ago.

Yes, I knew about this file. I'm not sure, however, what is the point of the pre-library meta/libraries.json files then, as they contain (a subset of) the same information. I had assumed that we'll be transitioning away from centrally stored files, and will be generating everything from the individual modules themselves. So, under that assumption, I expected the info in libraries.xml to be moved to the appropriate meta/libraries.json files, and then disappear. On second thought though, I now see that if someone requests the library list for boost_1_38_0, there would be no way to produce that from the json files.

Historical data is handled centrally, so it would be redundant and error prone to store it in the library repos (e.g. if a library was pulled from a release, but wasn't updated accordingly).

Right... but what is the point of the json files then? Wait, I think I figured it out... the release script generates (would generate) the release-specific info from the json files, then puts (would put) that into libraries.xml?

As you've probably noticed by now, the categories are in the xml file.

Right. This index.html is what "bpm index" generates, on the basis of what you have currently installed. It scans for meta/libraries.json files, and builds the list. So it would've been more convenient for me if the category names in the json are the full, human-readable names, rather than the identifiers, as I'd like to avoid downloading a separate category list. But I see how this might create a problem for the script that generates libraries.xml, and I also see why we can no longer change "workarounds" to "Workarounds" for consistency. A compromise might be to add category_name: [] to the json files and keep the current category: [] as is. Or, I could just hardcode the names and be done with it. :-)