Notes |
|
(0041094)
|
Brad King
|
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
|
2016-05-25 19:05
|
|
Brad, would it be possible to retry download afterwards? |
|
|
(0041107)
|
Brad King
|
2016-05-26 09:01
|
|
|
|
(0041112)
|
Ilya
|
2016-05-31 12:56
|
|
Brad,
Will it continue download or start it over? |
|
|
(0041113)
|
Brad King
|
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
|
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
|
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
|
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
|
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
|
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
|
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. |
|