MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008833CMakeCMakepublic2009-04-02 04:082016-06-10 14:30
ReporterTobias Rudolph 
Assigned ToBrad King 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionmoved 
PlatformOSOS Version
Product VersionCMake-2-6 
Target VersionFixed in Version 
Summary0008833: Xcode projects need to be build twice to capture changes in template files
DescriptionI have a problem with compiled CUDA source code and the Xcode generator. (The CUDA sources are compiled with the "NVIDIA (R) Cuda compiler driver" into C-code)

The behavior can be demonstrated using this simple example:

I have a file called "main.template":
----
#include <iostream>

int main()
{
   std::cout << "Hello world!\n";
   return 0;
}
----

my CMakeLists.txt looks like this:
----
project( XcodeTest )
cmake_minimum_required( VERSION 2.6 )

get_filename_component( TEMPLATE main.template ABSOLUTE )
add_custom_command( OUTPUT main.cpp
 COMMAND cp
 ARGS ${TEMPLATE} main.cpp
 DEPENDS main.template
)
set_source_files_properties( main.cpp PROPERTIES GENERATED TRUE )
add_executable( program main.cpp main.template )
----

As you can see, when a rebuild is done, the template gets copied to "main.cpp" which in turn is compiled and linked. This works great in Xcode. But, whenever I change the template, i.e. my CUDA sources, I have to run the build twice to make the changes appear in the test program. It looks like the custom command is executed during the first run and the generated file gets compiled in the second.

Steps To Reproduce
Additional InformationExample project attached. cmake version 2.6-patch 3
TagsNo tags attached.
Relationships
Attached Filesgz XcodeTest.tar.gz (649) 2009-04-02 04:08
https://public.kitware.com/Bug/file/2149/XcodeTest.tar.gz
zip QtBug.zip (3,089) 2009-04-30 10:55
https://public.kitware.com/Bug/file/2201/QtBug.zip
Issue History
Date ModifiedUsernameFieldChange
2009-04-02 04:08Tobias RudolphNew Issue
2009-04-02 04:08Tobias RudolphFile Added: XcodeTest.tar.gz
2009-04-30 10:54Daniel BlezekNote Added: 0016270
2009-04-30 10:55Daniel BlezekFile Added: QtBug.zip
2009-09-14 15:25Bill HoffmanStatusnew => assigned
2009-09-14 15:25Bill HoffmanAssigned To => Brad King
2009-09-17 10:42Brad KingNote Added: 0017588
2012-08-13 10:37Brad KingStatusassigned => backlog
2012-08-13 10:37Brad KingNote Added: 0030534
2016-06-10 14:27Kitware RobotNote Added: 0041534
2016-06-10 14:27Kitware RobotStatusbacklog => resolved
2016-06-10 14:27Kitware RobotResolutionopen => moved
2016-06-10 14:30Kitware RobotStatusresolved => closed

Notes
(0016270)
Daniel Blezek   
2009-04-30 10:54   
Also occurs for Qt
(0017588)
Brad King   
2009-09-17 10:42   
It looks like Xcode re-runs the custom command on the first rebuild, but it does not recognize that main.cpp changed after that. On the second rebuild it sees that main.cpp changed and then recompiles it.

My guess is that Xcode checks all the file timestamps at the beginning of processing each target and pre-computes which rules need to run and in what order. The problem is that nothing in the Xcode project tells it that the custom rule produces main.cpp because that part is all done through makefiles.

Xcode has very weak support for custom commands. Each one must be a custom build phase. Currently we use just one custom build phase which always runs a shell script to run "make" to update all custom rules in the target. However, the one custom build phase does not list any of the real inputs or outputs.

We may need to list all the inputs and outputs of all the custom commands handled by the helper makefile in the custom build phase. This would tell Xcode that those files might change. Unfortunately I suspect this might cause Xcode to treat *all* the outputs as if they have changed and then recompile all of them even if only one really regenerated. Furthermore, if a chain of dependent custom commands needs to run they may have to be in separate build phases so that no file is listed as both an input and output of a phase. Generating this properly will require a graph algorithm to compute a series of phases each running mutually independent custom commands.

In summary, this is a non-trivial problem to solve without help from new Xcode features.
(0030534)
Brad King   
2012-08-13 10:37   
Sending issues I'm not actively working on to the backlog to await someone with time for them.

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 or contributor who has the bandwidth to take it on.
(0041534)
Kitware Robot   
2016-06-10 14:27   
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.