[cmake-developers] Adding argument "OPTIONAL" to find_package() and add_subdirectory

[Clinton Stimpson]

On Jun 8, 2011, at 12:08 PM, Alexander Neundorf wrote:

> On Tuesday, June 07, 2011 02:34:06 PM Eric Noulard wrote:
>> 2011/6/7 Alexander Neundorf <neundorf at kde.org>:
>>> On Monday, June 06, 2011 03:26:03 PM Brad King wrote:
>>>> On 06/04/2011 06:30 AM, Alexander Neundorf wrote:
>> [...]
>> 
>>>>> What do you think about adding the keyword OPTIONAL to
>>>>> add_subdirectory ?
>>>>> 
>>>>> Both have been proven useful, the one for find_package() especially
>>>>> for packagers.
>>>> 
>>>> Ditto previous response.  These commands are primitives.  We should not
>>>> extend them with features unrelated to their basic purpose.
>>> 
>>> While this is correct, it also keeps cmake a bit low-level.
>>> For this reason, we created such macros in KDE.
>>> Now our developers write stuff outside KDE, so either they can't use it,
>>> or they create copies of these files.
>>> This may be ok, but having 50 or 100 versions of these files and macros
>>> around in the net, some probably differing slightly, is also not a nice
>>> situation.
>> 
>> Then it is possible to create a new CMake module,
>> 
>> say
>> 
>> UseEnhancedConfigure.cmake
>> 
>> which could be included in CMake as a contributed module maintained by KDE
>> dev. This new module would define something like:
>> 
>> optional_find_package().
>> optional_add_subdirectory()
>> 
>> this would make the feature available upstream, thus available outside KDE
>> and does not add extra feature to builtin configure.
> 
> I can't think of any reason why somebody would want to use 
> find_package(...without REQUIRED) instead of optional_find_package().
> 
> Can somebody else see a reason ?
> 
> 
>>> These two OPTION features in this email are IMO features which are useful
>>> in many projects and which would make using cmake-based projects easier
>>> for users (people compiling the software), since they could expect that
>>> if packages can be disabled, that this will be done via an option with a
>>> name which always follows the same scheme.
>> 
>> I totally agree with that but I think it does not implies this has to be
>> done by builtin find_package/add_subdirectory ?
> 
> Well, it doesn't have to.
> But if packagers requested this for something in KDE, they will also want this 
> for non-KDE projects.
> And I see no reason why this shouldn't be the default for _every_ non-REQUIRED 
> package.
> This would make the options available for cmake-based projects more 
> consistent.
> This issue comes up regularly from new users.
> 
> So, I don't see a reason why such an option should not be the default 
> behaviour and why I should rely on an external extension.

Just something that came to mind... what if one wanted one cmake option that corresponds with multiple find_package()'s.

But then wouldn't the following work for that case?
option(MYOPTION... )
set(FOO_OPTION ${MYOPTION} CACHE INTERNAL "")
set(BAR_OPTION ${MYOPTION} CACHE INTERNAL "")
find_package(FOO)
find_package(BAR)

Clint