From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2021-10-09 18:57:37
On 10/9/21 9:54 PM, John Maddock via Boost wrote:
> On 09/10/2021 18:11, Andrey Semashev via Boost wrote:
>> On 10/9/21 6:59 PM, John Maddock via Boost wrote:
>>> On 08/10/2021 16:10, Peter Dimov via Boost wrote:
>>>> Andrey Semashev wrote:
>>>>> Or you could conditionally enable ICU support based on CMake config
>>>>> option.
>>>>> We do something like this in Boost.Filesystem:
>>>>>
>>>>> https://github.com/boostorg/filesystem/blob/ec93082b6b54cd734b236638e7c4ba76e3b639e7/CMakeLists.txt#L15-L21
>>>>>
>>>>>
>>>> The closest example is
>>>>
>>>> https://github.com/boostorg/locale/blob/33d06c0c4be7f9bcfb05e200c72f752e9777261c/CMakeLists.txt#L83-L100
>>>>
>>>>
>>>>
>>> Thanks for the examples everyone, much appreciated.
>>>
>>> I confess I'm having a hard time seeing how a configuration option is
>>> better than the user simply adding the dependency to their executable
>>> CMake file?
>> If you mean ICU dependency then that's exposing Boost.Regex
>> implementation details (which is what an internal dependency is) to
>> users. At least, make it a Boost.Regex target for users to depend on.
> Making it a separate target does make sense to me.
>>
>> However, a config option has a configurability advantage. For example, a
>> user who consumes a product that uses Boost.Regex may choose whether the
>> whole product will depend on ICU or not. Personally, I would prefer this
>> kind of flexibility.
>
> I don't see how this can work - either the code includes
> boost/regex/icu.hpp in which there is a dependency, or it doesn't and
> there is no dependency.
>
> In other words it's a software design issue whether the dependency
> exists or not, there's nothing an end user can configure.
Is there no other backend an application could use instead of ICU?