Boost logo

Boost :

From: Phil Endecott (spam_from_boost_dev_at_[hidden])
Date: 2020-08-25 15:19:52


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.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk