On Monday 27 February 2012, Brad King wrote: > On 2/27/2012 3:37 PM, Michael Wild wrote: > > On 02/27/2012 09:15 PM, Alexander Neundorf wrote: > >> When the FooConfig.cmake has been found, Foo_FOUND is set to TRUE: > >> // Set a variable marking whether the package was found. > >> > >> std::string foundVar = this->Name; > >> foundVar += "_FOUND"; > >> > >> This means it is true in all cases that the Config.cmake file has been > >> found (and the version was compatible). > > The find_package command is acting as a primitive like find_library from > the point of view of setting Foo_DIR, and that can be tested directly to > see if the config file was found. That leaves room to change the way > we set Foo_FOUND. We could add a policy that in NEW behavior unsets > Foo_FOUND completely before loading FooConfig. After FooConfig has been > loaded it detects whether Foo_FOUND is now defined. If set, use that > value. If not set, set it to true as it is now. That will give the > FooConfig file a chance to set the result.
Sounds good. Do you think that needs a policy ? The code currently does: // Set a variable marking whether the package was found. std::string foundVar = this->Name; foundVar += "_FOUND"; this->Makefile->AddDefinition(foundVar.c_str(), found? "1":"0"); (I forgot the last line in my initial mail). So the variable is set afterwards unconditionally. The only condition where it would make a difference is if inside a FooConfig.cmake file there would be a check whether Foo_FOUND is already TRUE. I can do that. > >> * how to handle COMPONENTS ? > > > > I like that proposal. I'm also quite unhappy with how components are > > handled in config-mode. > > With the approach I suggest above it will be up to FooConfig to determine > this. > > Another approach is to add an API to give FooConfigVersion access to the > list of desired components. If the package version file encodes a known > list of available components it would be able to report UNSUITABLE if a > requested component is missing. Then find_package would move on to > another candidate. This might confuse users that expect a particular > location to be found because it wouldn't report that it is missing a > component and instead silently ignore it. It is probably better to let > FooConfig report a message that says its Foo doesn't have the component. Yes, I agree that putting the component-handling into the version file sounds a bit unexpected. Alex -- 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
