[CMake] xcode project and static library dependencies

[Bill Hoffman]

On 1/18/2011 2:40 PM, Brad King wrote:
> On 1/18/2011 2:12 PM, Nick Kledzik wrote:
>> When I use cmake to create a Makefile, the resulting main executable
>> is placed in the build directory tree next to the Makefile.
>
> This is where CMake puts files in single-configuration generators.
>
>> 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.
>
> This is where CMake puts files in multi-configuration generators.
>
> Both of the above are expected default behaviors.  Both can be
> changed by CMake properties like RUNTIME_OUTPUT_DIRECTORY and
> its per-configuration equivalent.  All CMake generators must
> honor these.
>
>> None of these locations are the "native" location
>> where Xcode would put a build result.
>
> Xcode has settings like CONFIGURATION_BUILD_DIR to control
> where the build outputs go.  This already works.  Is there
> some reason your changes cannot use these?
>
> My understanding is that the main problem with the current generator
> is all the extra build phases and OTHER_LDFLAGS stuff used to deal
> with link line ordering and static libraries.  This is what Bill
> summarized:
>
> On 1/13/2011 3:41 PM, Bill Hoffman wrote:
>> - have a static library show up more than once on a link line
>> - be able to specify the order of static libraries on the link line
>> - be able to relink and executable when a static library that it
> depends on is rebuilt.
>
> I'm more interested in a solution to implementation issues like these
> than in interface details like where output files go.
>
> -Brad
>
So, for Xcode and VS IDE, CMake will place things in directories like 
Debug, Release.

For example, you should get something like this:

${RUNTIME_OUTPUT_DIRECTORY}/Debug/myexe

Xcode does support building multiple configurations like Debug, Release, 
etc.  Where is the "native" location for those files?

I don't think we want an extra copy stage.

BTW, it might make more sense to move this to the cmake-developers 
mailing list.

http://www.cmake.org/cmake/help/mailing.html


-Bill