Re: [CMake] Can/should we specify optional dependencies

From: John Maddock (jz.maddock_at_[hidden])
Date: 2021-10-09 18:54:55

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.

Thanks, John.

-- 
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus