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

[Eric Noulard]

2011/6/8 Alexander Neundorf <neundorf at kde.org>:
> 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 ?

Our e-mails crossed each-other.

Yes you are right default behavior of making find_package(...without REQUIRED)
This is a different story for add_subdirectory.

>> > 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.

Again I agree for find_package since the extra behavior seems backward
compatible,
(I need more time to think about it)
you'll have to take care of name collision with existing user defined
OPTION though.


-- 
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org