On 2/16/2012 8:19 AM, Alexander Neundorf wrote:
Comments, objections ?
The entire point of find_package's interface is that the caller does not need to care how the package is found, and the actual method used for the find can change under the hood. Ideally every package would provide a package config file in its installation and we would never need Find modules. In that case having the extra keyword in every find_package call would be ugly. If you don't like the error message then you are free to write find_package(Foo NO_MODULE) anywhere you want. Perhaps you can add an alternative keyword so that this can be written find_package(Foo CONFIG) instead for those authors who want to do so. Furthermore if you want to guarantee that a Find module is used then add a mode like find_package(Foo MODULE) so that the command knows that it is an error if FindFoo does not exist in CMAKE_MODULE_PATH. In any of the above modes the error message can be more explicit. It is up to the author of the project to choose to do this. I do not want it to be required. For the default case perhaps the wording can be better than it is now. Currently the wording is trying to cover both the case that the developer of the code is reading it and the case that an end user is reading it while running cmake to build a project. The two cases are very different. This is not the first time we've had to deal with messages that are readable by developers but not by users and vice versa. I wonder if we should introduce some kind of use case mode setting that tells CMake who will be reading the messages. Then they can be tailored more effectively to the context. -Brad -- 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
