View Issue Details [ Jump to Notes ] [ Print ]
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.

Additional InformationExample project attached. cmake version 2.6-patch 3
TagsNo tags attached.
Attached Filesgz file icon XcodeTest.tar.gz [^] (649 bytes) 2009-04-02 04:08
zip file icon QtBug.zip [^] (3,089 bytes) 2009-04-30 10:55

 Relationships

  Notes
(0016270)
Daniel Blezek (reporter)
2009-04-30 10:54

 Also occurs for Qt
(0017588)
Brad King (manager)
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 (manager)
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 (administrator)
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.

 Issue History
Date Modified Username Field Change
2009-04-02 04:08 Tobias Rudolph New Issue
2009-04-02 04:08 Tobias Rudolph File Added: XcodeTest.tar.gz
2009-04-30 10:54 Daniel Blezek Note Added: 0016270
2009-04-30 10:55 Daniel Blezek File Added: QtBug.zip
2009-09-14 15:25 Bill Hoffman Status new => assigned
2009-09-14 15:25 Bill Hoffman Assigned To => Brad King
2009-09-17 10:42 Brad King Note Added: 0017588
2012-08-13 10:37 Brad King Status assigned => backlog
2012-08-13 10:37 Brad King Note Added: 0030534
2016-06-10 14:27 Kitware Robot Note Added: 0041534
2016-06-10 14:27 Kitware Robot Status backlog => resolved
2016-06-10 14:27 Kitware Robot Resolution open => moved
2016-06-10 14:30 Kitware Robot Status resolved => closed

Copyright © 2000 - 2018 MantisBT Team