Re: Symlinking headers instead of copying them?
Re: Symlinking headers instead of copying them?
- Subject: Re: Symlinking headers instead of copying them?
- From: Scott Tooker <email@hidden>
- Date: Thu, 26 Oct 2006 10:29:38 -0700
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
The best way to deal with this is to mark the headers as private to
the framework (select the Headers build phase of the framework
target and set the header files to have a "Private" role).
This is actually what I already do, but I think I'll need to modify
it.
Currently I stick the private headers in the (shared)
TARGET_BUILD_DIR (the public ones go inside the framework at the
usual location. Projects that use the framework have the shared
TARGET_BUILD_DIR in their HEADER_SEARCH_PATHS so that they can find
the headers.
One alternative that springs to mind is setting up a symlink inside
the TARGET_BUILD_DIR pointing to the header folder inside the
framework SOURCE_ROOT. I'd probably skip the "copy headers" phase
for private headers and instead use a shell-script build phase to
make sure the symlink was in place. Projects that use the framework
could continue with the same HEADER_SEARCH_PATH and things should
still work without any changes, but thanks to the symlink I should
end up editing the file I think I'm editing when I wind up in a
header by hitting Command-D.
Not sure if I've conveyed what I'm talking about here but hopefully
you get the idea...
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.
Scott
_______________________________________________
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