On 11/20/2013 04:05 AM, Daniele E. Domenichelli wrote: >> The "this->SetError/return false" logic for these errors should be >> replaced by "this->IssueMessage(cmake::FATAL_ERROR,...)/return true" >> to switch it to a fatal error. The signature should be extended >> to provide an option to get the error information back without >> causing a CMake Error so that the caller can handle it. > > What about setting the STATUS variable to > "some number different from 0;<algo> check failed" instead? > In this way the default behaviour won't change and there is no need to > extend the signature, but if you check the STATUS variable, you will be > able to issue a fatal error. > Also if download fails in some other way, the error raised is not fatal, > therefore in this way it looks more coherent.
Once a command reports an error CMake will not generate the project so it is not worth allowing the configuration to do much after that. Failure of file(DOWNLOAD) should either be a cmake::FATAL_ERROR or just a STATUS setting with no CMake Error. The signature needs a way for CMake to know which one to do. I'm fine with changing the current non-fatal error to a fatal error in the next release. -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
