Re: Tagging the minimum C++ standard level for Boost libs

From: Edward Diener (eldiener_at_[hidden])
Date: 2020-12-15 19:35:07

On 12/15/2020 1:14 PM, Peter Dimov via Boost wrote:
> Edward Diener wrote:
>> I had previously proposed that we tag the minimum C++ standard level for
>> Boost libs by adding information to the json meta information in
>> libraries.json for each library. I would like to revisit that proposal,
>> which involved more elaborate suggestions, with this simpler overall
>> proposal: for each Boost C++ library whose minimum C++ standard level is
>> C++11 or above we add a json field called 'cxxstd' whose value 
>> corresponds
>> to one of the same values as currently exists in Boost.Build for the
>> 'cxxstd' feature, ie. 11,14,17,20, to the libraries.json file for that
>> library. This json value can then be used in Boost documentation of each
>> library to specify the minimum C++ standard level needed by an 
>> end-user in
>> order to use that library. Obviously we can also add "cxxstd": "03" for
>> the many Boost libraries which can still be used at the C++98/C++03
>> compilation level also, even though I would argue that not having a
>> "cxxstd" json field should mean C++98/C++03 by default. I would be 
>> willing
>> to create the necessary PRs for each library, as I have a pretty good
>> internal list of this information.
>>
>> The gist of this proposal is to make it much easier for end-users wishing
>> to use a Boost library to immediately know whether the library they wish
>> to use is usable at the C++ standard compilation level they are using for
>> compilation, without having to spend time searching for such information,
>> which is often not readily available, in the documentation of the library
>> they are considering.
> 
> I see nothing wrong with adding this field to meta/libraries.json. 
> However, libraries.json is not for end users. It's input to the scripts 
> that generate the libraries page. So if we add the field, we should also 
> change the scripts to read it and display it in the library list.

Of course !

> 
> Unfortunately all those scripts were written and maintained by Daniel 
> James who isn't available, so someone else would need to figure this out.

I can look at it once this information is added to libraries.json where 
appropriate. Without looking I will guess that Daniel James used Python, 
which I know pretty well, but if it is something else it should not be 
impossible to figure out.