Re: Framework subgroups, and Framework header directory creation
Re: Framework subgroups, and Framework header directory creation
- Subject: Re: Framework subgroups, and Framework header directory creation
- From: Joseph Goldstone <email@hidden>
- Date: Thu, 8 Jul 2004 21:57:12 -0700
On Jul 8, 2004, at 6:49 PM, Nick Zitzmann wrote:
On Jul 8, 2004, at 4:27 PM, Joseph Goldstone wrote:
Firstly, within a new Cocoa Framework project's "External Frameworks
and Libraries" group, there are two subgroups: "Linked Frameworks"
and "Other Frameworks". What is the difference between the two, and
if I am adding a .dylib or .framework created elsewhere to my
project, in which of these two should I place it? (Or should I place
it within "External Frameworks and Libraries" but outside the
subfolders?)
It doesn't matter. I usually put frameworks my applications directly
link to into the "Linked Frameworks" subgroup, and put frameworks that
I want to be able to search (but not link to) in the "Other
Frameworks" group. For example, if I want to add the Carbon framework
to a project, I add the ApplicationServices and CoreServices
frameworks into the "Other Frameworks" group, turn off both
frameworks' inclusion in the target, then add the Carbon framework
into the "Linked Frameworks" group.
Ah. So this is 'linked' as in ld and dyld, not 'linked' as in ln.
With that in mind...if I have things that are not frameworks at all,
e.g. static libraries, well, those I link against as well. Should
static libraries that might live outside of frameworks go under 'Linked
Frameworks' as well? If so, is it just string length that is having
this be named 'Linked Frameworks' vs. 'Linked Frameworks and
Libraries'? If that is true, then I think I completely understand this
point now.
Secondly, in the generated .framework product, there is no Headers
directory (parallel to Resources in the hierarchy). The Xcode
documentation of the Headers build phase says that it "Installs
header files with Public or Private roles in the appropriate
locations in the product." [their capitalization of Public and
Private]. That is absolutely the only mention I can find of what
goes on in this phase. How do I set my header files to be Public or
Private?
It was more intuitive in Project Builder and Xcode legacy targets than
it is in Xcode native targets. To set header files to be public or
private in a native target, you need to click on the target and, in
the table view in the project's window, choose the appropriate option
from the pop-up menu that appears in each header's row under the
"Role" column. It took me a while to find that...
That point in the WWDC Keynote where Steve is showing Spotlight, and he
demonstrates that it found the words "Half Dome" in tiny type on a PDF
of a map of the quadrangle that contains Yosemite? Well, I want that
kind of searching for applications...something where I could type
'Role' and it would find all UI components with that string in them.
Hmm, there's probably a MacHack prize in there somewhere...
Anyway with the header file roles now set to 'Public' I get Headers
appropriately included in my framework. My next problem is that adding
that framework to a new project, and tucking it under 'Linked
Frameworks' as described above, and including it in the 'Frameworks &
Libraries' build phase of the target, doesn't have the code in the new
project seeing the header files.
If I add to my current build style's Header Search Paths the full-on
absolute path to the generated headers in their installed location, all
is well, but that seems like the sort of thing that should happen
automatically when I put the framework in the project.
I tried putting the first framework in the Headers build phase of the
new project as well as that project's Frameworks & Libraries build
phase, but still no joy. At least hand-coding the path to the headers
directory works in the Header Search Paths. But this still seems
awkward. What am I doing wrong?
_______________________________________________
xcode-users mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/xcode-users
Do not post admin requests to the list. They will be ignored.