[CMake] file( DOWNLOAD ) problem

[Robert Dailey]

To do MD5 checks, I need to somehow record the expected MD5 somewhere,
which isn't very maintainable.

I provide a list of third party libraries that CMake should download
from a central third party repository here at work. It is a trusted
source, because we know it is, so we don't need to verify the MD5.
However, if I could request the MD5 first, and then download, then
compare the MD5 the server gave me with what I actually downloaded,
that would certainly work just to verify the complete file was
downloaded.

Other than that, I'll have to rely on the status of the operation...
but I don't like that the destination file is created prior to any
writes being possible by CMake (it can't write anything if no data was
received, so why doesn't it create the file once it has a write
buffer?)

On Wed, Sep 26, 2012 at 5:30 PM, David Cole <david.cole at kitware.com> wrote:
> On Wed, Sep 26, 2012 at 6:28 PM, David Cole <david.cole at kitware.com> wrote:
>> On Wed, Sep 26, 2012 at 6:12 PM, Eric Noulard <eric.noulard at gmail.com> wrote:
>>>
>>> 2012/9/27 David Cole <david.cole at kitware.com>:
>>> > With file(DOWNLOAD, you should always use the EXPECTED_MD5 argument (or
>>> > EXPECTED_HASH with nightly CMake, or 2.8.10 or later) to verify success.
>>>
>>> I bet this is not always possible.
>>> Why would you **always** know some hash of the file you are downloading?
>>
>>
>> If you don't, then you can't know if it came down correctly or not,
>> even if STATUS tells you that the download succeeded... So. I would
>> say if you don't know the expected hash, then you can't trust the
>> source of the download. I personally would not use file(DOWNLOAD to
>> grab anything of importance unless I knew what it's expected hash is.
>>
>>>
>>>
>>> May be STATUS is usable in this case as well:
>>>
>>> "If STATUS var is specified the status of the operation will be put in
>>> var. The status is returned in a list of length 2. The first element
>>> is the numeric return value for the operation, and the second element
>>> is a string value for the error. A 0 numeric error means no error in
>>> the operation"
>>>
>>> --
>>> Erk
>>> Le gouvernement représentatif n'est pas la démocratie --
>>> http://www.le-message.org
>>
>>
>> Yes, you can see how file(DOWNLOAD is used from ExternalProject by
>> inspecting one of its generated download scripts. Here's an example
>> for downloading the tarball for the zlib project:
>>
>>
>> message(STATUS "downloading...
>>      src='http://zlib.net/zlib-1.2.7.tar.gz'
>>      dst='/Users/davidcole/Downloads/zlib-1.2.7.tar.gz'
>>      timeout='none'")
>>
>> file(DOWNLOAD
>>   "http://zlib.net/zlib-1.2.7.tar.gz"
>>   "/Users/davidcole/Downloads/zlib-1.2.7.tar.gz"
>>   SHOW_PROGRESS
>>   EXPECTED_MD5;60df6a37c56e7c1366cca812414f7b85
>>   # no TIMEOUT
>>   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
>> 'http://zlib.net/zlib-1.2.7.tar.gz' failed
>>   status_code: ${status_code}
>>   status_string: ${status_string}
>>   log: ${log}
>> ")
>> endif()
>>
>> message(STATUS "downloading... done")
>
>
>
> Plus..... if you use the EXPECTED_MD5 argument, then file(DOWNLOAD can
> short-circuit/by-pass the network activity and associated wait time if
> the file already exists and already has the expected hash value... So
> it saves gobs and gobs of time for people executing the same
> file(DOWNLOAD command repeatedly.
>
> :-)