MantisBT - CMake
View Issue Details
0015904CMakeModulespublic2016-01-05 10:332016-06-10 14:31
Jaak Ristioja 
Daniele E. Domenichelli 
normalmajoralways
closedmoved 
 
 
0015904: ExternalProject UPDATE_DISCONNECTED does not work with custom UPDATE_COMMAND
This CMakeLists.txt file:
  CMAKE_MINIMUM_REQUIRED(VERSION 3.1)
  PROJECT(test NONE)
  INCLUDE(ExternalProject)
  SET_PROPERTY(DIRECTORY PROPERTY EP_UPDATE_DISCONNECTED 1)
  ExternalProject_Add(sf GIT_REPOSITORY "https://github.com/sharemind-sdk/vm_m4.git" [^] UPDATE_COMMAND ${CMAKE_COMMAND} -E echo "Hello, World!")

yields in the following `make`output:
  Scanning dependencies of target sf
  [ 14%] Creating directories for 'sf'
  [ 28%] Performing download step (git clone) for 'sf'
  Cloning into 'sf'...
  Already on 'master'
  Your branch is up-to-date with 'origin/master'.
  [ 42%] No patch step for 'sf'
  make[2]: *** No rule to make target 'sf-prefix/src/sf-stamp/sf-skip-update', needed by 'sf-prefix/src/sf-stamp/sf-configure'. Stop.
  CMakeFiles/Makefile2:67: recipe for target 'CMakeFiles/sf.dir/all' failed
  make[1]: *** [CMakeFiles/sf.dir/all] Error 2
  Makefile:83: recipe for target 'all' failed
  make: *** [all] Error 2

Same error with UPDATE_DISCONNECTED set on the external project itself.
Tested with cmake-3.3.2 and cmake-3.4.1.
No tags attached.
Issue History
2016-01-05 10:33Jaak RistiojaNew Issue
2016-01-07 15:52Brad KingAssigned To => Daniele E. Domenichelli
2016-01-07 15:52Brad KingStatusnew => assigned
2016-01-12 08:01Daniele E. DomenichelliNote Added: 0040196
2016-01-12 10:29Brad KingNote Added: 0040199
2016-04-12 08:16Craig ScottNote Added: 0040843
2016-06-10 14:29Kitware RobotNote Added: 0042908
2016-06-10 14:29Kitware RobotStatusassigned => resolved
2016-06-10 14:29Kitware RobotResolutionopen => moved
2016-06-10 14:31Kitware RobotStatusresolved => closed

Notes
(0040196)
Daniele E. Domenichelli   
2016-01-12 08:01   
The custom update command currently behaves differently compared to the normal update commands. I believe this is because this is either not used by anyone, or used as 'UPDATE_STEP ""', because otherwise we would have noticed before that the update step is not performed.

I created the ExternalProject_fix_custom_update_command to fix this issue:

  ExternalProject: Fix custom update command
  https://cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=7bf25bc [^]

@Brad can you have a look at it sinces it changes slightly the behaviour?
Does this kind of change require an entry in Help/release/dev?
(0040199)
Brad King   
2016-01-12 10:29   
Re 0015904:0040196: I think the change is okay. We can always revert it if it regresses something, but I think the new behavior is more consistent. Actually, if all the branches of the if() tree set "always" then it can be factored out and set unconditionally.

Please add a release note calling attention to it. I'll put it in the appropriate section when consolidating release notes for 3.5. Thanks!
(0040843)
Craig Scott   
2016-04-12 08:16   
Not sure what happened, but I think this problem still exists in CMake 3.5.1. A slightly different CMakeLists.txt file generates a similar error, but only with Unix Makefiles (Ninja works fine):


--------------
cmake_minimum_required(VERSION 3.2)

project(Armadillo-download NONE)

include(ExternalProject)
ExternalProject_Add(Armadillo-download
                    URL http://sourceforge.net/projects/arma/files/armadillo-6.700.3.tar.gz [^]
                    URL_MD5 fac5aa395fcb5b9e52791f041827d872
                    TIMEOUT 180
                    UPDATE_DISCONNECTED 1
                    SOURCE_DIR "Armadillo-src"
                    BINARY_DIR "Armadillo-build"
                    CONFIGURE_COMMAND ""
                    BUILD_COMMAND ""
                    INSTALL_COMMAND ""
                    TEST_COMMAND ""
)

--------------

Interestingly, if you remove the "UPDATE_DISCONNECTED 1" line, the error does not occur, so it seems like the behaviour has changed slightly from the original bug report, but is still not fully fixed.
(0042908)
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.