<div class="gmail_quote">On Tue, Jan 18, 2011 at 2:12 PM, Nick Kledzik <span dir="ltr"><<a href="mailto:kledzik@apple.com">kledzik@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div><div></div><div class="h5">On Jan 18, 2011, at 5:30 AM, Bill Hoffman wrote:<br>
>>> I have changes that cause cmake to produce an Xcode project in which the<br>
>>> targets do not have the extra phases, and the dependencies are set up such<br>
>>> that incremental builds work efficiently!<br>
>>><br>
>>> But I'm having some impedance mismatches between where Xcode want the<br>
>>> build results to be and where cmake wants them. Xcode (like many makefiles)<br>
>>> has the concept of a normal build and an "install" build. But when cmake<br>
>>> runs it builds some test programs using the xcodebuild command line, but<br>
>>> does not specify the "install" action but then expects to find the resulting<br>
>>> executable in the install location.<br>
>>><br>
>>> I'm sure I could change TryCompileCode() to add "install" to the<br>
>>> xcodebuild line, but it seems like lots of other cmake scripts will have the<br>
>>> same expectations. I playing with trying to get Xcode to always do an<br>
>>> "install". I tried creating xcode projects with the initial (not install)<br>
>>> locations being where cmake wants them, but xcode seems to not do the<br>
>>> internal dependency analysis properly when the intermediate results are not<br>
>>> within BUILD_PRODUCTS_DIR.<br>
>>><br>
>>> What is the cmake model for where the results of a build go?<br>
>><br>
>> Putting the results where the native tool expects them is fine. CMake makes<br>
>> no guarantees about where build products go. If a native tool has no<br>
>> expectations, we try to hide build results underneath the "CMakeFiles/"<br>
>> directories in the build tree to avoid cluttering a developer's view of the<br>
>> build tree with stuff they mostly don't need to see...<br>
>> I don't think there are any hard requirements w.r.t. build products<br>
>> locations. Although where libraries and executables end up is important for<br>
>> the CMake generated install rules to work.<br>
>> Feel free to change things around experimentally if that makes it easy to<br>
>> work with newer Xcode versions. The test suite will very likely tell us if<br>
>> things have gone awry.<br>
>><br>
><br>
> That is not entirely true....<br>
><br>
> Things like EXECUTABLE_OUTPUT_PATH and target location properties have<br>
> to work without an extra install step. What do you mean CMake expects<br>
> to find things in install locations? CMake does need to be able to<br>
> find executables after the build is run. It also needs to be able to<br>
> place them via location properties.<br>
<br>
<br>
</div></div>Take for example a simple test case that just builds one source file into an executable via"<br>
ADD_EXECUTABLE(main main.c)<br>
When I use cmake to create a Makefile, the resulting main executable is placed in the build directory tree next to the Makefile.<br>
When I use cmake to create a xcode project, the resulting main executable is placed in a subdirectory named Debug of the build directory tree.<br>
<br>
The method cmCoreTryCompile::FindOutputFile() seems to know about this because it looks for executables in the build directory then in <build directory>/Debug and <build directory>/Release.<br>
<br>
None of these locations are the "native" location where Xcode would put a build result. So, I need to create xcode projects that place/copy the resulting executables somewhere that cmake universe expects.<br>
<br>
Now I am wondering if I should add a copy-files-phase in the executable target to copy the resulting binary to the build directory. That would make xcode output be like Makefile output.<br>
<font color="#888888"><br>
-Nick<br>
<br>
<br>
</font></blockquote></div><br>Where does the Xcode equivalent of "add_executable(main main.c)" naturally go?<br><br>