[CMake] xcode project and static library dependencies

[David Cole]

On Tue, Jan 18, 2011 at 2:12 PM, Nick Kledzik <kledzik at 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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20110118/c8227781/attachment.htm>