[CMake] xcode project and static library dependencies

Nick Kledzik kledzik at apple.com
Tue Jan 18 14:12:33 EST 2011


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




More information about the CMake mailing list