Peter Dimov wrote:
Phil Endecott wrote: ...
4. These generated files are checked in at https://github.com/tzlaine/text/tree/master/include/boost/text/data
https://github.com/tzlaine/text/tree/master/include/boost/text/detail surely?
Err yes, both I think. It's doesn't matter much though.
if we go with the strict interpretation and decide that
{0x0028, 0x0029, bidi_bracket_type::open}, {0x0029, 0x0028, bidi_bracket_type::close}, {0x005B, 0x005D, bidi_bracket_type::open}, {0x005D, 0x005B, bidi_bracket_type::close}, {0x007B, 0x007D, bidi_bracket_type::open}, {0x007D, 0x007B, bidi_bracket_type::close},
is a derived work of a Unicode data file, I see no way of ever having a Unicode library in Boost.
I see various possible ways forward though none is particularly appealing: 1. A run-time dependency on libicu, getting libicu to do all the work, as Boost.Locale does. 2. A run-time dependency on libicu that generates these tables by interrogating libicu at start-up, and then using Zach's code. 3. Getting users to download the Unicode data files and run the scripts at Boost compile time. 4. Making an exception to the licensing policy. 5. Removing this from Boost.Text, keeping just the UTFn conversion code and anything else that doesn't depend on the problematic data files (as I advocated in my review). Regards, Phil.