Re: [boost] Metadata pull requests

Subject: Re: [boost] Metadata pull requests
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2014-08-21 08:18:41

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/