• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag
 

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Archiving problems with xcode 4.3
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Archiving problems with xcode 4.3


  • Subject: Re: Archiving problems with xcode 4.3
  • From: Mirko Viviani <email@hidden>
  • Date: Wed, 29 Feb 2012 17:34:08 +0100

On Feb 28, 2012, at 9:19 PM, Quincey Morris wrote:

> On Feb 28, 2012, at 12:05 , Mirko Viviani wrote:
>
>> The Copy Headers phase does not have an input destination field, but it uses the PUBLIC_HEADERS_FOLDER_PATH, PRIVATE_HEADERS_FOLDER_PATH and also DSTROOT.
>>
>> Public and Private headers path are set to /usr/local/include
>> Skip Install to Yes
>> DSTROOT to $(BUILT_PRODUCTS_DIR)
>>
>> Obviously my main project (Lyn) search path contains $(BUILT_PRODUCTS_DIR)/usr/local/include
>
> Well, yes, that's kind of what I was talking about. You're telling the copy to copy the files *somewhere* into the intermediate build products hierarchy, but you're assuming that $(BUILT_PRODUCTS_DIR) is always the same every time Xcode does a compile/link/archive. My point is that it isn't.

I'm not assuming that $(BUILT_PRODUCTS_DIR) is always the same, infact as I said before, the search path contains $(BUILT_PRODUCTS_DIR)/usr/local/include, so Xcode can change the prefix path dinamically.

It didn't work because in Xcode 3 I used $(CONFIGURATION_BUILD_DIR) that don't work for archiving.

> Your assumption is a left-over from the Xcode 3 universe.

I'm not sure I follow your point. I don't use a single tool, but the one's I need.
Xcode, custom makefiles, sh, python and ruby scripts.
But maybe I'm missing something else.

>>> I'm not sure sub-projects are even supported in Xcode 4 any more, but a workspace with your projects at the top level is a better way to go.
>>
>> I don't know but they seem to work. Anyway I can move them at top level, but at the moment the priority is to get the debugger working.
>
> I think I'm suggesting that if you put the library projects at the the top level, that *will* get the debugger working.


After your msg I've switched from LLDB to GDB and it magically worked as usual.

I'll surely retry workspaces but first of all I need a break :) and upgrade my macbook to Lion and Xcode4! :)

--
Ciao,
Mirko    http://www.lynapp.com




 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden


References: 
 >Archiving problems with xcode 4.3 (From: Mirko Viviani <email@hidden>)
 >Re: Archiving problems with xcode 4.3 (From: Quincey Morris <email@hidden>)
 >Re: Archiving problems with xcode 4.3 (From: Mirko Viviani <email@hidden>)
 >Re: Archiving problems with xcode 4.3 (From: Quincey Morris <email@hidden>)
 >Re: Archiving problems with xcode 4.3 (From: Mirko Viviani <email@hidden>)
 >Re: Archiving problems with xcode 4.3 (From: Quincey Morris <email@hidden>)

  • Prev by Date: Re: 4.3 question and old Developer folder
  • Next by Date: Re: Xcode 4 editor scripting - help!
  • Previous by thread: Re: Archiving problems with xcode 4.3
  • Next by thread: Another Xcode Bug?
  • Index(es):
    • Date
    • Thread