On 19 Aug 2014 at 14:53, Daniel James wrote:
Would you be okay if people added extra optional fields i.e. would your parser skip them without problem? I think between myself and Robert we can add some good optional metadata extensions.
It's possible to add extra fields, but I'd rather keep this file fairly small and static. It shouldn't take a lot of work to write it, and shouldn't need to be updated too often. It's also quite likely that it will be replaced by something else in the future, especially if we ever have a package management system. It's not intended to be a permanent solution.
You read my mind :) I was actually thinking a bit before that though: right now if you pull a Boost submodule you have no automated way of figuring out just its minimal dependency set. My current client has their build system yank the entire of Boost for only a few libraries which blows a 1Gb of expensive SSD space per CI test instance, and it would be super nice to create a "Boost lite" consisting solely of my forthcoming lightweight "Boost emulation in C++11 STL in a single header file" library which eliminates the need for Boost.Build, Boost.Test and Boost.Core on C++11/14 and the minimum Boost libraries you actually want and need. The next step after, of course, is a web page which lets you download any subset of Boost you choose :)
If that isn't possible for you, any objection to an extra json file appearing in meta/*?
Not really, and even if I did, I don't have any special authority here. I'd suggest making a proposal in a new thread. My concern would be how much work this would require from maintainers. Currently the metadata file is optional, and fairly simple.
As with everything in Boost, it's all opt in. If you add the support, you get your library into the fancy new tools. If not, you don't.
Btw. if you're doing something with test data, it might be worth looking at 'status/explicit-failures-markup.xml' and seeing if you can incorporate that in some manner.
I'm more keen on seeing libraries ranked in descending order by how well they are maintained. Eric's libraries are particularly well maintained, and therefore should bubble to the top. But thanks for the tip, I didn't know about that. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/