On Tue, Jan 18, 2011 at 2:12 PM, Nick Kledzik <kled...@apple.com> wrote:
> 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 > > > Where does the Xcode equivalent of "add_executable(main main.c)" naturally go?
_______________________________________________ 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