MantisBT - CMake
View Issue Details
0012412CMakeCMakepublic2011-08-19 01:412016-06-10 14:31
Yuri 
Kitware Robot 
normalminoralways
closedmoved 
PCWindowsXP
CMake 2.8.5 
 
0012412: Visual studio 2010 doesn't execute dependent steps.
I'm trying to force rebuild of external project when some files in my system change. To do this I added custom build step which depends on file and build step depends on it.

But it seems that Visual Studio 2010 checks dependencies for custom build tool only once and computes targets which will be built (it has one target called "Custom build tool").

So to trigger build of external project I has to run build twice.
See attached project.
Log from first build:
1>------ Build started: Project: ZERO_CHECK, Configuration: Debug Win32 ------
2>------ Build started: Project: Subproject, Configuration: Debug Win32 ------
2> Files in external project changed, triggering build.
3>------ Build started: Project: ALL_BUILD, Configuration: Debug Win32 ------
3> Build all projects
========== Build: 3 succeeded, 0 failed, 1 up-to-date, 0 skipped ==========

From second build:
1>------ Build started: Project: ZERO_CHECK, Configuration: Debug Win32 ------
2>------ Build started: Project: Subproject, Configuration: Debug Win32 ------
2> Performing build step for 'Subproject'
2>
2>
2> Microsoft (R) Visual Studio Version 10.0.40219.1.
2>
2> Copyright (C) Microsoft Corp. All rights reserved.
2>
2> 1>------ Build started: Project: ZERO_CHECK, Configuration: Debug Win32 ------
2>
2> 2>------ Build started: Project: ALL_BUILD, Configuration: Debug Win32 ------
2>
2> 2> Build all projects
2>
2> ========== Build: 2 succeeded, 0 failed, 1 up-to-date, 0 skipped ==========
2>
2> Performing install step for 'Subproject'
2>
2>
2> Microsoft (R) Visual Studio Version 10.0.40219.1.
2>
2> Copyright (C) Microsoft Corp. All rights reserved.
2>
2> 1>------ Build started: Project: ZERO_CHECK, Configuration: Debug Win32 ------
2>
2> 2>------ Build started: Project: ALL_BUILD, Configuration: Debug Win32 ------
2>
2> 2> Build all projects
2>
2> 3>------ Build started: Project: INSTALL, Configuration: Debug Win32 ------
2>
2> 3> -- Install configuration: "Debug"
2>
2> 3> -- Up-to-date: C:/Program Files/othertest/./otherlib.lib
2>
2> ========== Build: 3 succeeded, 0 failed, 1 up-to-date, 0 skipped ==========
2>
2> Completed 'Subproject'
3>------ Build started: Project: ALL_BUILD, Configuration: Debug Win32 ------
3> Build all projects
========== Build: 3 succeeded, 0 failed, 1 up-to-date, 0 skipped ==========

As you can see, on the second run VS understands that file changed and triggers action.
No tags attached.
zip ep_customstep_test.zip (1,070) 2011-08-19 01:41
https://public.kitware.com/Bug/file/4012/ep_customstep_test.zip
Issue History
2011-08-19 01:41YuriNew Issue
2011-08-19 01:41YuriFile Added: ep_customstep_test.zip
2011-08-19 09:25David ColeAssigned To => David Cole
2011-08-19 09:25David ColeStatusnew => assigned
2011-08-19 16:54David ColeNote Added: 0027250
2011-08-22 04:05YuriNote Added: 0027258
2012-08-13 15:40David ColeStatusassigned => backlog
2012-08-13 15:40David ColeNote Added: 0030621
2012-11-21 14:57David ColeNote Added: 0031651
2012-11-21 15:02David ColeAssigned ToDavid Cole =>
2016-06-10 14:28Kitware RobotNote Added: 0041888
2016-06-10 14:28Kitware RobotStatusbacklog => resolved
2016-06-10 14:28Kitware RobotResolutionopen => moved
2016-06-10 14:28Kitware RobotAssigned To => Kitware Robot
2016-06-10 14:31Kitware RobotStatusresolved => closed

Notes
(0027250)
David Cole   
2011-08-19 16:54   
SUGGESTED WORK-AROUND:

I have not analyzed and figured out exactly what's going wrong here yet... but I do have an example that works for you, if you'd like to use it as a work-around in the meantime.

This CMakeLists.txt file works, triggers a rebuild of the Subproject when force_build.txt changes (in the same build), and does nothing on the next build after that.


# <CMakeLists.txt>
cmake_minimum_required(VERSION 2.8)

project(test)

include(ExternalProject)

ExternalProject_Add(Subproject
    SOURCE_DIR "${CMAKE_SOURCE_DIR}/Subproject"
    CMAKE_GENERATOR "Visual Studio 10"
    CMAKE_ARGS -DCMAKE_INSTALL_PREFIX:PATH=<INSTALL_DIR>
    BUILD_IN_SOURCE 0
    )
ExternalProject_Add_Step(Subproject CheckRebuild
    COMMENT "Files in external project changed, triggering build."
    DEPENDERS build
    DEPENDEES configure
# DEPENDERS configure
# DEPENDEES download
    DEPENDS force_build.txt
    )

add_library(testlib testfile.c)
# </CMakeLists.txt>


I added the:

  CMAKE_ARGS -DCMAKE_INSTALL_PREFIX:PATH=<INSTALL_DIR>

simply so that I could reliably do a sample build/install. I would get install errors (because I do not run as admin, and cannot install into Program Files by default) when running without it.

If you really want to trigger just the *build* step and onward, use:

  DEPENDERS build
  DEPENDEES configure

If you want to trigger the *configure* step and onward, use:

  DEPENDERS configure
  DEPENDEES download


I'm not sure why it matters yet, but the custom step has to be inserted exactly in between two existing and connected steps in order to run reliably in Visual Studio 10.

Additionally, you do not have to use a file trigger here, although you certainly may. You could simply say, "ALWAYS 1" instead of "DEPENDS force_build.txt" and the configure or build (and later) steps will always run when you do a build in the containing solution. However, it appears to be true that if you do use the "ALWAYS 1" *and* "DEPENDEES download" that you also have to explicitly declare an empty DOWNLOAD_COMMAND using:

  DOWNLOAD_COMMAND ""


Wow. Very painful and mystifying to try all these different scenarios. I do hope the suggested work-around is acceptable for you, for now.
(0027258)
Yuri   
2011-08-22 04:05   
Thanks for work-around, It's really mysterious, but it works.

I supposed that it could be fixed only by implementing custom commands as native msbuild targets.
(0030621)
David Cole   
2012-08-13 15:40   
Sending old, not-recently-updated issues to the backlog.

(The age of the bug alone means that nobody is actively working on it...)

If an issue you care about is sent to the backlog when you feel it should have been addressed in a different manner, please bring it up on the CMake mailing list for discussion. Sign up for the mailing list here, if you're not already on it: http://www.cmake.org/mailman/listinfo/cmake [^]

It's easy to re-activate a bug here if you can find a CMake developer who has the bandwidth to take it on, and ferry a fix through to our 'next' branch for dashboard testing.
(0031651)
David Cole   
2012-11-21 14:57   
Un-assigning bugs that are not on the active roadmap, which no developers are actively working on for the CMake 2.8.11 release.

If one gets put back on the roadmap, re-assign it appropriately at that time.
(0041888)
Kitware Robot   
2016-06-10 14:28   
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.