View Issue Details [ Jump to Notes ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0012564CMakeCMakepublic2011-11-08 12:192012-10-01 13:22
ReporterAndras Lasso 
Assigned ToDavid Cole 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
PlatformWindows 7 & XPOSOS Version
Product VersionCMake 2.8.6 
Target VersionCMake 2.8.9Fixed in VersionCMake 2.8.9 
Summary0012564: Repeated git clones and build for external projects on Windows
DescriptionIt's extremely frustrating to use git external projects on Windows, mainly due to two problems.

1. CMake&git keeps downloading and building the project many times. This takes very long time on projects using VTK, ITK, Slicer, CTK, etc.

2. Many directory deletes that seems to occur during simple update/rebuild operations. If they fail to complete (because the directory is in use) then it leads to permanent git errors.

msysgit: 1.7.7.msysgit.1
TortoiseGit: 1.7.3.0
Steps To Reproduce1. Typical use case for re-clone and re-build problem:
-Start build in debug mode => git clone, re-build
-Start build in release mode => git clone(!), re-build
-Start build in debug mode => re-build(!)

This means that when building a project in two modes it does an extra clone and build step, which takes 2-3 hours on a larger project.

2. Typical use case for directory delete problem:
-Start build in debug mode
-Run the application in debug mode, keep the subproject binary directory (c:\devel\cmakegittest\cmakegittest-superbuild-bin4\cmakegittest-bin) as the current directory in the command-line window
-Start build in release mode => build fails due to "C:/devel/cmakegittest/cmakegittest-superbuild-bin4/cmakegittest" directory cannot be deleted - note that this is not the directory that was kept in the current command-line window

1>------ Build started: Project: cmakegittest, Configuration: Release Win32 ------
1>Performing download step (git clone) for 'cmakegittest'
1>Error removing directory "C:/devel/cmakegittest/cmakegittest-superbuild-bin4/cmakegittest".
1>CMake Error at cmakegittest-prefix/tmp/cmakegittest-gitclone.cmake:10 (message):
1> Failed to remove directory:
1> 'C:/devel/cmakegittest/cmakegittest-superbuild-bin4/cmakegittest'
1>Project : error PRJ0019: A tool returned an error code from "Performing download step (git clone) for 'cmakegittest'"
1>Build log was saved at "file://c:\devel\cmakegittest\cmakegittest-superbuild-bin4\cmakegittest.dir\Release\BuildLog.htm" [^]
1>cmakegittest - 1 error(s), 0 warning(s)
2>------ Skipped Build: Project: ALL_BUILD, Configuration: Release Win32 ------
2>Project not selected to build for this solution configuration
========== Build: 0 succeeded, 1 failed, 1 up-to-date, 1 skipped ==========

All repeated build attempts fail. The c:\devel\cmakegittest\cmakegittest-superbuild-bin4\cmakegittest cannot be opened in explorer. Killing the TGitCache.exe process solves the problem: the c:\devel\cmakegittest\cmakegittest-superbuild-bin4\cmakegittest directory disappears and repeated build attempts succeed.
Additional InformationAttached a sample CMakeLists.txt with that the above reported problems can be easily reproduced (it downloads and builds a small sub-project from github).
TagsNo tags attached.
Attached Filestxt file icon CMakeLists.txt [^] (1,414 bytes) 2011-11-08 12:19 [Show Content]

 Relationships
related to 0011403closedDavid Cole ExternalProject GIT_TAG 

  Notes
(0027786)
Andras Lasso (reporter)
2011-11-12 09:24

 Anybody experiencing this problem please add a comment to this issue. It would help in getting higher priority and thus quicker resolution.
(0027802)
Jean-Christophe Fillion-Robin (reporter)
2011-11-15 16:06

 This is a recurrent problem happening when doing slicer build. See http://slicer.cdash.org/viewBuildError.php?buildid=4598 [^]

What can we do to help fixing the problem ?
(0027804)
Tamas Heffter (reporter)
2011-11-15 19:20

 We've experienced the same problem using VTK and ITK as an external project on Windows, so instead of helping with the build process, it just multiplies the compilation time. It always clones the repository (however we're using the same git tag) and compiles the solution again.
(0027845)
Siavash Khallaghi (reporter)
2011-11-21 19:24

 This is very annoying problem. I would appreciate a quick fix.
(0028913)
Stefan Eilemann (reporter)
2012-03-14 05:23

 I would extend this bug to tweak the git download step to not clone when the repo is already there, but merely do a git checkout of the requested tag.
(0028914)
Stefan Eilemann (reporter)
2012-03-14 06:14

 I modified the git clone script to not re-clone every time. Maybe this helps somebody on this bug, or might be merged into upstream. Code is here: https://github.com/Eyescale/CMakeProjects/blob/master/CMake/UseExternal.cmake [^]
(0029092)
Jean-Christophe Fillion-Robin (reporter)
2012-04-07 16:25

 The problem still occurs using CMake 2.8.8 rc2. See [1]

The latest version of "git for windows" is being used. See [2]

It happens almost on a daily basis when doing the nightly configuring using either "Visual Studio 9 2008" or "Visual Studio 9 2008 Win64" generator.

The nightly takes care of cleaning the build folder using the ctest command "ctest_empty_binary_directory". See [3]

Within CMakeCache, for both the 32 and 64 bit build:
GIT_EXECUTABLE:FILEPATH=C:/Prgram Files (x86)/Git/bin/git.exe


The length of the path is also kept short.

  Source dir:
     C:\D\N\Slicer4

  Build dir:
     C:\D\N\Slicer-build-0


Stefan> Couldn;t find the file "UseExternal.cmake" on your github.


[1] http://slicer.cdash.org/viewBuildError.php?buildid=14326 [^]

[2] http://code.google.com/p/msysgit/downloads/detail?name=Git-1.7.9-preview20120201.exe&can=2&q=full+installer+official+git [^]

[3] https://github.com/Slicer/Slicer/blob/master/CMake/SlicerDashboardDriverScript.cmake#L109 [^]
(0029109)
Stefan Eilemann (reporter)
2012-04-10 03:23

 Jean-Christophe: The project has moved. New URL is: https://github.com/Eyescale/Buildyard/blob/master/CMake/UseExternal.cmake [^]
(0029344)
David Cole (manager)
2012-04-25 17:55

 Partial fix pushed to 'next' just now:

  http://public.kitware.com/gitweb?p=cmake.git;a=commitdiff;h=987c017f6b1b49ab832c244166e30e07260432da [^]

This fix is a better solution than using an existence test on a source tree with a ".git" directory in it because this fix WILL delete and re-clone when necessary IF (and only IF) the repository value changes.

The technique where you use the existence test of a ".git" folder to avoid deleting and then cloning will NOT work correctly across a repository change. (It may, however, appear to work if both repositories have the tagged commit that you're trying to grab, or you're using something like "origin/master" as the tag...)


Switching between Debug and Release:

By default, the "source" directory of an external project is in the build tree of its parent project (the one that's calling ExternalProject_Add), and on a per-configuration basis, it keeps track of which steps have been executed so far. The Debug build step is different than the Release build step. In order to avoid multiple downloads with a git repo when switching from Debug to Release and back, I'm going to have to do some further work... (That's why I've labeled this a 'partial fix'.)

The stamp files for each step are tracked on a per-configuration basis in multi-config development environments, but it seems like it would be beneficial for the source tree and the download/update step stamp files to be tracked on a configuration-independent basis.
(0029358)
David Cole (manager)
2012-04-27 11:42

 One problem I discovered with attempting to fix the remaining problem of "git clone is executed at least once for each config when switching from config to config in Visual Studio" ...

The problem is, even with the following extremely simple CMakeLists file that simply chains a bunch of custom commands together, and does not rely on ANY config-specific stamp files, there is no way to prevent Visual Studio from running the command sequence at least once in each config. It appears to track whether it has run the custom commands on a per-config basis.

The only solution (I think) is to do our own management using if(IS_NEWER constructs within a CMake script in order to prevent the second clone from happening. Painful, but still possible. I'll be working on that tactic.

Here's an example CMakeLists you can use if you want to experiment yourself:

cmake_minimum_required(VERSION 2.8.8)
project(abc)

set(script "${CMAKE_BINARY_DIR}/s.cmake")
file(WRITE "${script}" "
message(\"running \${CMAKE_CURRENT_LIST_FILE}\")
file(WRITE \"\${dir}/out\${n}.txt\" \"\${CMAKE_CURRENT_LIST_FILE}\")
")

add_custom_command(
  OUTPUT ${CMAKE_BINARY_DIR}/out1.txt
  COMMAND ${CMAKE_COMMAND} -Dn=1 -Ddir=${CMAKE_BINARY_DIR} -P ${script}
  )
add_custom_command(
  OUTPUT ${CMAKE_BINARY_DIR}/out2.txt
  COMMAND ${CMAKE_COMMAND} -Dn=2 -Ddir=${CMAKE_BINARY_DIR} -P ${script}
  DEPENDS ${CMAKE_BINARY_DIR}/out1.txt
  )
add_custom_command(
  OUTPUT ${CMAKE_BINARY_DIR}/out3.txt
  COMMAND ${CMAKE_COMMAND} -Dn=3 -Ddir=${CMAKE_BINARY_DIR} -P ${script}
  DEPENDS ${CMAKE_BINARY_DIR}/out2.txt
  )
add_custom_command(
  OUTPUT ${CMAKE_BINARY_DIR}/final.txt
  COMMAND ${CMAKE_COMMAND} -Dn=4 -Ddir=${CMAKE_BINARY_DIR} -P ${script}
  COMMAND ${CMAKE_COMMAND} -E copy ${CMAKE_BINARY_DIR}/out4.txt ${CMAKE_BINARY_DIR}/final.txt
  DEPENDS ${CMAKE_BINARY_DIR}/out3.txt
  )
add_custom_target(xyz ALL DEPENDS ${CMAKE_BINARY_DIR}/final.txt)
(0029362)
David Cole (manager)
2012-04-28 15:53

 Fix pushed to CMake's 'next' branch just now:

  http://public.kitware.com/gitweb?p=cmake.git;a=commitdiff;h=08db81e00807c1dfc6846e9b3228c54dfe37a67f [^]

After an initial build as Debug, and then switching to the Release config, the download script will run once in Release mode, too... but now the script tracks whether it has successfully completed using its own internal stamp file. So... even though the script runs once after switching to Release config, it's a no-op with an early exit, so avoids the pain of the potentially very long clone operation.

This seems like the best compromise since all custom commands run at least once in each VS config.

Please give it a try with the nighty CMake builds from tomorrow, or build your own, and let me know what you think. Add notes here over the next few days. If nothing else gets added during the coming week, I'll mark this as resolved, and we'll call it "fixed."
(0029382)
Andras Lasso (reporter)
2012-05-01 14:13

 Thanks a lot David. I've tested cmake-2.8.8.20120430-g7b49a-win32-x86 and it works correctly: the unnecessary clone and build operations are not performed anymore.
(0029401)
David Cole (manager)
2012-05-05 13:37

 Resolving as promised in previous note. Please re-open and attach more information if there is still a problem for anyone monitoring this issue.
(0031121)
David Cole (manager)
2012-10-01 13:22

 Closing resolved issues that have not been updated in more than 4 months.

 Issue History
Date Modified Username Field Change
2011-11-08 12:19 Andras Lasso New Issue
2011-11-08 12:19 Andras Lasso File Added: CMakeLists.txt
2011-11-10 11:14 David Cole Assigned To => David Cole
2011-11-10 11:14 David Cole Status new => assigned
2011-11-12 09:24 Andras Lasso Note Added: 0027786
2011-11-15 16:06 Jean-Christophe Fillion-Robin Note Added: 0027802
2011-11-15 19:20 Tamas Heffter Note Added: 0027804
2011-11-21 19:24 Siavash Khallaghi Note Added: 0027845
2012-01-02 13:07 David Cole Target Version => CMake 2.8.8
2012-03-14 05:23 Stefan Eilemann Note Added: 0028913
2012-03-14 06:14 Stefan Eilemann Note Added: 0028914
2012-04-07 16:25 Jean-Christophe Fillion-Robin Note Added: 0029092
2012-04-10 03:23 Stefan Eilemann Note Added: 0029109
2012-04-19 08:51 David Cole Target Version CMake 2.8.8 => CMake 2.8.9
2012-04-25 17:55 David Cole Note Added: 0029344
2012-04-25 17:57 David Cole Relationship added related to 0011403
2012-04-27 11:42 David Cole Note Added: 0029358
2012-04-28 15:53 David Cole Note Added: 0029362
2012-05-01 14:13 Andras Lasso Note Added: 0029382
2012-05-05 13:37 David Cole Note Added: 0029401
2012-05-05 13:37 David Cole Status assigned => resolved
2012-05-05 13:37 David Cole Fixed in Version => CMake 2.8.9
2012-05-05 13:37 David Cole Resolution open => fixed
2012-10-01 13:22 David Cole Note Added: 0031121
2012-10-01 13:22 David Cole Status resolved => closed

Copyright © 2000 - 2018 MantisBT Team