On 07/31/2012 02:30 PM, Alexander Neundorf wrote: > On Tuesday 31 July 2012, Bill Hoffman wrote: >> I wonder if we could just disable fatal error at the start of >> find_package optional. Then turn it back on at the end.
As I pointed out elsewhere in this thread fatal errors are just one way a failure can occur inside find_package when a package is broken. Total sandboxing is not realistic. Partial sandboxing just pushes the underlying problem on a given machine over the horizon. > One reason why I wanted it to be an error was to force people > to fix their install, make it is obvious that it is not the > fault of the buildsystem of the project being built, but of the > package being used. Yes. > I'm not sure it is better to fail relatively silently in this > case instead of complaining loudly that the package is broken. > > Users might wonder why it doesn't work, the devel package is > installed, in the right place, and still CMake doesn't pick it > up. IMO once find_package locates a package configuration file the corresponding package *has* been found. If the package is broken failure can occur at a number of different times: (1) The package config .cmake file reports a problem. (2) CMake succeeds but compilation fails due to a missing header (3) Compilation works but linking fails due to a missing library (4) Linking works but runtime fails due to a missing resource The sandboxing approach can only hope to ignore packages that will fail as case 1. Even that may not be desirable. If a package is broken it is better to fix it or explicitly request that it not be used than to automatically ignore it (silently or loudly). That way all failure cases for broken packages are resolved in the same way. > I can have a look how to make it not an error if the > find_package() is optional, if we really want that. I think a better solution is to allow specific package locations to be explicitly disallowed by the user. This gives them an option to deal with broken packages if they are not an admin on the machine capable of fixing it. That way if the package is an optional dependency and the only instance of it on the system is broken the user still has a way to move forward. I'm not sure how the interface might look or how to tell users they may activate it. David Cole suggested in a sibling to this message to lighten the error message in target info files to a warning along with setting <package>_FOUND to FALSE if the package is not required. This approach is complementary to the above proposal. -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
