Alexander Neundorf wrote: > On Friday 05 September 2008, Yann Cointepas wrote: >> 1) Why do I need Foo_FIND_QUIET in FooConfig.cmake ? >> First, I would like to display a message with the Foo version found if >> QUIET is not used.
Okay. >> 2) Why do I need Foo_FIND_REQUIRED in FooConfig.cmake ? >> FooConfig.cmake will be packaged and installed on various systems (in a >> Foo-devel package). Therefore, even if FooConfig.cmake is found, I need to >> check that its mandatory dependencies are found too before setting >> Foo_FOUND. For instance, I have a mandatory dependency on Boost and I would >> like to have the following code in FooConfig.cmake: > > Ok, this makes sense. I disagree. The fact that FooConfig.cmake was loaded means that Foo *was* found. It is up to the module to report other information for consumption by the project. Perhaps the project finding Foo just wants to load some documentation files from it and doesn't care about its linking dependencies. For this reason the find_package command in Config mode defines "found" to mean that the module was found and loaded. It is going to set Foo_FOUND to true after loading FooConfig.cmake no matter what the module does (unless it has a syntax error). Setting it inside the module will have no effect (though the fatal error message will prevent the overall configuration from succeeding). I do not recommend searching for required dependencies inside "FooConfig.cmake". The process that put it there in the first place should have hard-coded inside it the locations of all dependencies. If it comes with a system package file (like a .deb), then that file should have a dependency on the boost package and know where it will be installed. If it comes from the user having built and installed Foo, then that build/install process should have found boost on the machine already. Using a different boost could lead to problems, so the location should be hard-coded. > Brad, any objections to set these two variables always, also in Config mode ? > If not I can do that if you're not faster. It doesn't hurt to have them available. Please send me a proposed patch. Thanks, -Brad _______________________________________________ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
