On 03/13/2012 09:55 PM, Brad King wrote: > On Tue, Mar 13, 2012 at 4:43 PM, Alexander Neundorf <neund...@kde.org> wrote: >> We could also not set <pkg>_FIND_REQUIRED_<component>, or set it to "0" >> (which >> would mean it is not required). > > Even better. One can loop over the_FIND_COMPONENTS list and then test > the variable to see if it is really required or not. > >> Are there any compatibility issue to take into account ? >> Until now, there never was a OPTIONAL_COMPONENT, so every call to >> find_package(COMPONENTS ...) will work as before. > > I don't think there is a compatibility concern. A loop like the above > would just consider every component required when the package is > loaded by an older project that does not use the new keyword. > >> If somebody adds a OPTIONAL_COMPONENTS, this will add component entries to >> the >> FIND_COMPONENTS variable which have now _FIND_REQUIRED_ set to 0. >> The Find-module or Config-file may not be prepared to handle this. > > I do not think that is a problem. The calling project should only use > this option if the package to be found documents that it supports > optional components. This is the same as passing only components > documented by the package as known. > >> What is actually the purpose of the _FIND_REQUIRED_ variable ? >> It currently doesn't add any information compared to the list >> _FIND_COMPONENTS. Are you aware of any uses of this variable ? > > _FIND_REQUIRED_ came first. The entire feature was first added here: > > http://www.cmake.org/Bug/view.php?id=2771 > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9f625bea > > The _FIND_COMPONENTS list was added later because it is more convenient. > >> The argument parsing in cmFindPackage still has to decide what to do if a >> component appears multiple times. >> Error out ? >> REQUIRED always has priority over OPTIONAL ? >> Last one wins ? > > I think error is best. It's better to be explicit so authors do not > assume ether way.
IMO, using solely <pkg>_FIND_REQUIRED_<component> to indicate if a requested component is mandatory or optional is not sufficient. Consider the following use case: FIND_PACKAGE(Foo COMPONENTS X OPTIONAL_COMPONENTS Y) Suppose both X and Y do require a component A. AFAICS, this is a completely regular case and provides for a component that should conceptually be considered mandatory *and* optional. In {FindFoo,FooConfig}.cmake, it has proven to be very convenient to add such prerequisite components to Foo_FIND_COMPONENTS at the beginning in order to process all components in a unique manner later on. Which value should one set Foo_FIND_REQUIRED_A to? Instead, I'd suggest not to touch the value of Foo_FIND_REQUIRED_* but to add a further variable like Foo_FIND_OPTIONAL_*, as it is already done in 1a157e7. Then, just accept it if both variables are TRUE and leave it to {FindFoo,FooConfig}.cmake how to handle this case, i.e. bail out, prefer REQUIRED to OPTIONAL or whatever. IMO, this does neither imply inherent contradictions to be handled by FIND_PACKAGE() nor constrain {FindFoo,FooConfig}.cmake's freedom to process components in any suitable way. Finally, one could simply allow arbitrary duplicates after COMPONENTS and OPTIONAL_COMPONENTS. Note that this does not affect the question whether there should be a sole comprehensive Foo_FIND_COMPONENTS variable or an additional Foo_FIND_OPTIONAL_COMPONENTS one. Regards, Michael -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers