On 11/21/2013 10:46 AM, David Cole wrote: >> I'm fine with changing the current non-fatal error to a fatal error >> in the next release. > > Would this be: > (1) an unconditional, always-in-effect change? > (2) a policy with a NEW behavior? > (3) a change activated only by use of a new keyword argument to > file(DOWNLOAD ? > > File download errors are quite common for many different reasons.... > I'm not sure I like the idea of triggering a CMake fatal error for a > corrupt download.
Even without this change it is already an error. If it is used in a build-time script the script will exit with an error when finished. If it is in a CMakeLists.txt file, CMake will not generate the project when finished. The concern is that in either case the caller of file(DOWNLOAD) may immediately do something with the downloaded content. By using EXPECTED_HASH, a caller says it expects very specific content. If it does not match we should not let the caller proceed to do something with unexpected content. Therefore option (1) that you list above is the best fix. Read the rest of the thread in more detail. We propose adding an additional signature to allow scripts to avoid a CMake Error and handle the failure themselves. In either case we should not have a non-fatal error. -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
