[cmake-developers] [CMake] xcode project and static library dependencies

Mon Mar 7 07:33:31 EST 2011

Nick,

We are using a modification on your patch internally.
Few things
1) It breaks projects that have resources. Fix is to attach the Executable
to only the 'copy to cmake build dir' phase. Even after the mailinglist
discussion I'm unsure of the need for this?
XCode basically claims it is a recursive dependency as the executable file
is added as a depenency on the "Copy Files" phase.

2) POST_BUILD targets stopped working. Re-added the code that uses those
(Before the copy-files target, maybe it should be after? I Really don't
understand the copy to cmake build dir phase.

Attached the original Patch from Nick modified to work with lastest git
master + two fixes mentioned above.

/Johan

On Sun, Feb 20, 2011 at 2:43 PM, Johan Björk <phb at spotify.com> wrote:

> Hi Nick,
>
> Any updates on this patch?
>
> Cheers
> /Johan
>
>
> On Thu, Jan 20, 2011 at 2:08 AM, Nick Kledzik <kledzik at apple.com> wrote:
>
>> >
>> > BTW, it might make more sense to move this to the cmake-developers
>> mailing list.
>> >
>> I've transfered this thread to the developer list.  See below for
>> continuation..
>>
>>
>> On Jan 18, 2011, at 12:42 PM, Bill Hoffman wrote:
>>
>> > 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?
>> As I said, it is per-user xcode settings.  You cannot infer the location
>> from source tree cmake has access to.
>>
>> At build time, the location is known within xcode.  So, I added a
>> copy-file phase to have xocde copy the resulting binary from the "native"
>> location to the standard location the cmake expects.  There is little
>> overhead for this.
>>
>> I've now have a patch which:
>> 1) preserves link order
>> 2) builds libraries into the xcode native location
>> 4) removes pre and post shell script phases previously used to fix
>> dependency problems
>> 3) xcode projects now have proper dependencies
>>
>> WIth this cmake patch, I can build CMake.xcodeproject, open it in xcode,
>> build-all, set the current target to be "cmake", make a source change, hit
>> build, and have xcode just compile that one file, re-archive the library,
>> then re-link cmake tool.  I also debugged all this in Xcode by setting
>> arguments for the cmake tool and hitting the build-and-debug within xcode!
>>
>> Attached is the patch from cmake-2.8.3 sources:
>>
>>
>>
>> This cmake also creates an xcode project that builds LLVM.  It is still
>> not quite optimal because there are a bunch of cases where custom rules
>> cause a custom make file to be generated which is executed from within xcode
>> via a shell script phase.  Xcode does not now which files the script might
>> modify, so xcode has to be conservative and re-check all timestamps.  There
>> are ways to add custom scripts with specified input and output files in
>> xcode.  I may get to fixing that someday...
>>
>>
>> How does one run the test suite?  I saw the instructions about building
>> cmake for make, then executing "make Experimental".  I did that and all 184
>> or 184 tests passed.  But it looks like this is running the cmake generated
>> makefiles - not cmake generated xcode projects.
>>
>> -Nick
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> cmake-developers mailing list
>> cmake-developers at cmake.org
>> http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20110307/88d9724e/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Patch-from-Nick.patch
Type: application/octet-stream
Size: 19722 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20110307/88d9724e/attachment-0003.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-Update-to-Nick-s-patch-to-not-create-a-circular-refe.patch
Type: application/octet-stream
Size: 1277 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20110307/88d9724e/attachment-0004.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-xcode-Re-add-the-post-build-phase.patch
Type: application/octet-stream
Size: 1878 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20110307/88d9724e/attachment-0005.obj>