On Jan 18, 2011, at 5:30 AM, Bill Hoffman wrote: >>> I have changes that cause cmake to produce an Xcode project in which the >>> targets do not have the extra phases, and the dependencies are set up such >>> that incremental builds work efficiently! >>> >>> But I'm having some impedance mismatches between where Xcode want the >>> build results to be and where cmake wants them. Xcode (like many makefiles) >>> has the concept of a normal build and an "install" build. But when cmake >>> runs it builds some test programs using the xcodebuild command line, but >>> does not specify the "install" action but then expects to find the resulting >>> executable in the install location. >>> >>> I'm sure I could change TryCompileCode() to add "install" to the >>> xcodebuild line, but it seems like lots of other cmake scripts will have the >>> same expectations. I playing with trying to get Xcode to always do an >>> "install". I tried creating xcode projects with the initial (not install) >>> locations being where cmake wants them, but xcode seems to not do the >>> internal dependency analysis properly when the intermediate results are not >>> within BUILD_PRODUCTS_DIR. >>> >>> What is the cmake model for where the results of a build go? >> >> Putting the results where the native tool expects them is fine. CMake makes >> no guarantees about where build products go. If a native tool has no >> expectations, we try to hide build results underneath the "CMakeFiles/" >> directories in the build tree to avoid cluttering a developer's view of the >> build tree with stuff they mostly don't need to see... >> I don't think there are any hard requirements w.r.t. build products >> locations. Although where libraries and executables end up is important for >> the CMake generated install rules to work. >> Feel free to change things around experimentally if that makes it easy to >> work with newer Xcode versions. The test suite will very likely tell us if >> things have gone awry. >> > > That is not entirely true.... > > Things like EXECUTABLE_OUTPUT_PATH and target location properties have > to work without an extra install step. What do you mean CMake expects > to find things in install locations? CMake does need to be able to > find executables after the build is run. It also needs to be able to > place them via location properties.
Take for example a simple test case that just builds one source file into an executable via" ADD_EXECUTABLE(main main.c) When I use cmake to create a Makefile, the resulting main executable is placed in the build directory tree next to the Makefile. 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. 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. 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. 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. -Nick _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
