[CMake] file(DOWNLOAD) and HTTP 302 (redirect)

[David Cole]

I'm pretty sure the original intent was for file(DOWNLOAD ...) to not raise
errors so that scripts can analyze status and log and decide what to do next
rather than forcing a CMake error...

I recently added EXPECTED_MD5 to file(DOWNLOAD in the 'next' branch of
CMake. If a download fails when there's an expected MD5 sum given, then it
*does* raise an error. Perhaps you'll find that useful in the next
release...

Cheers,
David C.


On Fri, Jun 4, 2010 at 7:55 AM, David Cole <david.cole at kitware.com> wrote:

> What if you do something this...? What do status and log tell you?
>
> set(remote "http://......")
> set(local "some file name")
>
> file(DOWNLOAD
>
>   "${remote}"
>
>   "${local}"
>
>   STATUS status
>
>   LOG log)
>
>
> list(GET status 0 status_code)
>
> list(GET status 1 status_string)
>
>
> if(NOT status_code EQUAL 0)
>
>   message(FATAL_ERROR "error: downloading '${remote}' failed
>
>   status_code: ${status_code}
>
>   status_string: ${status_string}
>
>   log: ${log}
>
> ")
>
> endif()
>
>
>
> On Fri, Jun 4, 2010 at 4:00 AM, Michael Wild <themiwi at gmail.com> wrote:
>
>> When downloading something from http://downloads.sourceforge.net/... you
>> always get a 302 redirect to one of the many mirror servers. Unfortunately,
>> it seems that file(DOWNLOAD ...) doesn't follow the redirect, but just stops
>> and leaves an empty file behind. No error, no nothing. Is this intentional?
>>
>> I'd rather not use a specific mirror...
>>
>> Michael
>> _______________________________________________
>> 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://www.cmake.org/mailman/listinfo/cmake
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20100604/02ae5ce3/attachment.htm>