Clarification: I was referring to intermediate build product files, not final libraries and executables. For the most part, nobody should care where their intermediate files are as long as everything works.<br><br><div>Sorry for the mis-communication.</div>
<div><br></div><div><br><div class="gmail_quote">On Tue, Jan 18, 2011 at 8:30 AM, Bill Hoffman <span dir="ltr"><<a href="mailto:bill.hoffman@kitware.com">bill.hoffman@kitware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div><div class="h5">>> 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>
</div></div>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>
<font color="#888888"><br>
-Bill<br>
</font></blockquote></div><br></div>