Subject: Re: [boost] Library list generated from meta/libraries.json files
From: Peter Dimov (lists_at_[hidden])
Date: 2015-01-05 12:38:58
Daniel James wrote:
> On 5 January 2015 at 14:10, Peter Dimov <lists_at_[hidden]> 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:
> 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
> 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.
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
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. :-)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk