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/ec93082b6b54cd734b236638e7c4ba76...
The closest example is
https://github.com/boostorg/locale/blob/33d06c0c4be7f9bcfb05e200c72f752e9777...
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. Thanks, John. -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus