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

Mon Mar 7 08:17:24 EST 2011

and wow, the patch I just sent is broken because cmXCodeObject->Print() has
sideffects! :(

Will send a patch that fixes ->Print() when I have some extra time.

/Johan

On Mon, Mar 7, 2011 at 1:33 PM, Johan Björk <phb at spotify.com> wrote:

> 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
>>>
>>>
>>
>

-- 
Johan Björk
Team Lead, Development Tools
Spotify

This e-mail (including any attachments) may contain information that is
confidential and/or privileged. It is intended only for the recipient(s).
If you have reason to believe that you are not the intended recipient of
this e-mail, please contact the sender immediately and delete the e-mail
from your computer.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20110307/505b4a91/attachment.html>
-------------- 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: 1354 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20110307/505b4a91/attachment-0002.obj>