Re: Symlinking headers instead of copying them?
Re: Symlinking headers instead of copying them?
- Subject: Re: Symlinking headers instead of copying them?
- From: leenoori <email@hidden>
- Date: Thu, 26 Oct 2006 20:16:53 +0200
El 26/10/2006, a las 19:29, Scott Tooker escribió:
On Oct 26, 2006, at 10:19 AM, leenoori wrote:
El 26/10/2006, a las 18:51, Scott Tooker escribió:
So it sounds like you want to have headers associated with your
frameworks at development time, but when you ship the frameworks
to users you want to keep from shipping "private" headers.
Yes that's true but it's not the problem I'm trying to solve...
The problem is that when I do a Command-D and wind up in a header,
if I perform any edits to the header then I'm editing the wrong
copy; the one which is effectively a temporary copy stored in my
built products folder. What I want to do is edit the "real" header
in the source root of the framework.
It's not something I do very often but it has occasionally bitten
me that I make edits in the wrong file and they end up getting
clobbered.
Ah, now I understand. The bad news is that there is no good way
around this problem (for now). This is known bug in Xcode (and one
that I would hit quite often when working on Xcode).Scott
For the time being, this workaround seems to be fine:
0. This assumes your shared frameworks and other projects all go into
a shared built products location
1. In the framework either get rid of the copy headers phase entirely
(if all your headers are private) or cleanse it of all private
headers (leaving only public ones)
2. Add a shell script build phase to the framework which does this:
cd "${TARGET_BUILD_DIR}"
ln -s -v "${SOURCE_ROOT}" "${PRODUCT_NAME}"
Of course, in the real script you'd have error checking and checks
for an already existing symlink etc, but you get the idea.
3. Keep your other projects that use the framework just as they were
before, with TARGET_BUILD_DIR in the HEADER_SEARCH_PATHS
4. Rebuild your code sense index
Testing shows that this works around the issue nicely. Code sense
still works for items defined in the framework headers. Doing Command-
D on a framework symbol takes you to the "real" header in the
framework source tree instead of the "temporary" header. When you do
something like:
#import "MyFramework/MyHeader.h"
Xcode successfully finds the right header:
${TARGET_BUILD_DIR}/MyFramework/MyHeader.h"
Which after resolving the symlink is really:
${SOURCE_ROOT}/MyHeader.h
So your edits stick and don't get clobbered. The price you pay for
this is that you lose the ability to maintain a distinction between
public, private and project headers: you've now only really got
"public" (in the framework bundle) and "everything" (in the framework
source root); for me that's an acceptable compromise but for others
it may not be.
I'd avoid trying to pervert your build setup to try and work around
this UI bug. In the end, I'm guessing you'll cause other problems
to surface with your builds.
Understood, but looking at the costs here (one shell script which I
can stick in a shared location and use across all framework projects
without modification) I think it's an acceptable trade off.
Thanks for your help, Scott. And glad to hear that this issue is
already known to Apple...
Cheers
_______________________________________________
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