On 03/13/2012 06:30 PM, Brad King wrote:
> On 3/13/2012 1:12 PM, Alexander Neundorf wrote:
>> Setting CMP0018 to new would mean that the project supports only those
>> component-aware packages which follow that new convention.
>
> Yes, that cannot be a requirement to use
>
> cmake_minimum_required(VERSION 2.8.8)
>
> or whatever version of CMake introduces the policy as that would set
> it to NEW implicitly. We cannot make this a special case because then
> it would simply not be a policy. It introduces a requirement on the
> CMake version-awareness of a project's dependencies instead of just
> the project.
>
> > Some users/developers would prefer if there was a more strict definition of
> > how the COMPONENTS arguments should be handled.
>
> My proposal only requires the small change to CMake already under
> discussion and makes it possible for projects to provide package
> configuration files that handle components in a nice way. It also
> does not preclude the possibility of a future convention. However,
> any "strict definition" of behavior would *force* every project to
> adapt to it even if it doesn't make sense just because it made
> sense for a few *other* projects.
A further point why Foo_FOUND shouldn't be set by FIND_PACKAGE()
based on the Foo_*_FOUND variables of the mandatory components:
In {FindFoo,FooConfig}.cmake, I use to remove each component from
Foo_FIND_COMPONENTS once it has been processed, so at the end, the
remaining components are the unknown ones. This is quite handy and
makes it easy to provide Foo_*_FOUND==FALSE for the latters.
Even making Foo_FIND_COMPONENTS read-only is not a suitable solution:
IIRC, there is a consensus that {FindFoo,FooConfig}.cmake is expected
to search prerequisite but unrequested components by itself, and such
an unrequested prerequisite is expected to determine Foo_FOUND along
with the other mandatory components. A r/o Foo_FIND_COMPONENTS tends
to be incomplete in this regard.
The conclusion is that Foo_FIND_COMPONENTS is not guaranteed - at
no time - to hold all components intended to determine Foo_FOUND,
so an automatism like the one in 796ad77 is too short-sighted, IMO.
Instead, I'd agree that it should really be left to FooConfig.cmake
completely which value is assigned to Foo_FOUND in the end - unless
FooConfig.cmake doesn't do this or cannot be loaded. There might be
arbitrary findings the author of FooConfig.cmake wants to consider
for this purpose.
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
