(0041094)
Brad King (manager)
2016-05-25 16:35

Specifically, file(DOWNLOAD) calls could be taught to use the INACTIVITY_TIMEOUT. An absolute TIMEOUT is not suitable when the file size and connection speed is not known.

(0041096)
Ilya (reporter)
2016-05-25 19:05

Brad, would it be possible to retry download afterwards?

(0041107)
Brad King (manager)
2016-05-26 09:01

Recent changes merged in this topic:

Merge topic 'ExternalProject-improve-retry'
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e07f7e6c [^]

improve retry support. Please try it out. See also discussion here:

[Patch] ExternalProject: fix retry logic if error occurs
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/16421 [^]

(0041112)
Ilya (reporter)
2016-05-31 12:56

Brad,

Will it continue download or start it over?

(0041113)
Brad King (manager)
2016-05-31 13:06

Re 0016109:0041112: IIUC the retry will start over. The file(DOWNLOAD) command has no way to request a continued download.

(0041114)
Ilya (reporter)
2016-05-31 13:49

Brad,

How hard would it be to add this functionality to file(DOWNLOAD)? I'm thinking to ask / hire someone to do that.

(0041115)
Brad King (manager)
2016-05-31 13:57

Re 0016109:0041114: file(DOWNLOAD) is just a CMake language binding to the curl library. If that library has a way to do this then it will just be a matter of exposing it through an option.

(0041116)
Ilya (reporter)
2016-05-31 14:05
edited on: 2016-05-31 14:07

Brad,

I'm not sure about the library, but the utility has `-C` or `--continue-at`.

In my case this is the preferred solution, because for some reason CMake stops downloading at about 25%. Starting it all over again to stop at 23% or at 28% doesn't solve the issue.

(0041117)
Ilya (reporter)
2016-05-31 14:17

Brad,

I know that 3.6 is scheduled for tomorrow. Would it be possible to include this change in 3.6.1 ?

(0041118)
Brad King (manager)
2016-05-31 14:52

Re 0016109:0041117: No. Patch releases are only for regressions and documentation updates. The feature set for 3.6 is already frozen as announced on the dev list.

(0043006)
Kitware Robot (administrator)
2016-06-10 14:29

Resolving issue as `moved`.

This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.

Notes
(0041094) Brad King (manager) 2016-05-25 16:35	Specifically, file(DOWNLOAD) calls could be taught to use the INACTIVITY_TIMEOUT. An absolute TIMEOUT is not suitable when the file size and connection speed is not known.

(0041096) Ilya (reporter) 2016-05-25 19:05	Brad, would it be possible to retry download afterwards?

(0041107) Brad King (manager) 2016-05-26 09:01	Recent changes merged in this topic: Merge topic 'ExternalProject-improve-retry' https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e07f7e6c [^] improve retry support. Please try it out. See also discussion here: [Patch] ExternalProject: fix retry logic if error occurs http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/16421 [^]

(0041112) Ilya (reporter) 2016-05-31 12:56	Brad, Will it continue download or start it over?

(0041113) Brad King (manager) 2016-05-31 13:06	Re 0016109:0041112: IIUC the retry will start over. The file(DOWNLOAD) command has no way to request a continued download.

(0041114) Ilya (reporter) 2016-05-31 13:49	Brad, How hard would it be to add this functionality to file(DOWNLOAD)? I'm thinking to ask / hire someone to do that.

(0041115) Brad King (manager) 2016-05-31 13:57	Re 0016109:0041114: file(DOWNLOAD) is just a CMake language binding to the curl library. If that library has a way to do this then it will just be a matter of exposing it through an option.

(0041116) Ilya (reporter) 2016-05-31 14:05 edited on: 2016-05-31 14:07	Brad, I'm not sure about the library, but the utility has `-C` or `--continue-at`. In my case this is the preferred solution, because for some reason CMake stops downloading at about 25%. Starting it all over again to stop at 23% or at 28% doesn't solve the issue.

(0041117) Ilya (reporter) 2016-05-31 14:17	Brad, I know that 3.6 is scheduled for tomorrow. Would it be possible to include this change in 3.6.1 ?

(0041118) Brad King (manager) 2016-05-31 14:52	Re 0016109:0041117: No. Patch releases are only for regressions and documentation updates. The feature set for 3.6 is already frozen as announced on the dev list.

(0043006) Kitware Robot (administrator) 2016-06-10 14:29	Resolving issue as `moved`. This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.

Issue History
Date Modified	Username	Field	Change
2016-05-25 16:08	Ilya	New Issue
2016-05-25 16:35	Brad King	Note Added: 0041094
2016-05-25 19:05	Ilya	Note Added: 0041096
2016-05-26 09:01	Brad King	Note Added: 0041107
2016-05-31 12:56	Ilya	Note Added: 0041112
2016-05-31 13:06	Brad King	Note Added: 0041113
2016-05-31 13:49	Ilya	Note Added: 0041114
2016-05-31 13:57	Brad King	Note Added: 0041115
2016-05-31 14:05	Ilya	Note Added: 0041116
2016-05-31 14:07	Ilya	Note Edited: 0041116
2016-05-31 14:17	Ilya	Note Added: 0041117
2016-05-31 14:52	Brad King	Note Added: 0041118
2016-06-10 14:29	Kitware Robot	Note Added: 0043006
2016-06-10 14:29	Kitware Robot	Status	new => resolved
2016-06-10 14:29	Kitware Robot	Resolution	open => moved
2016-06-10 14:29	Kitware Robot	Assigned To	=> Kitware Robot
2016-06-10 14:31	Kitware Robot	Status	resolved => closed

Relationships