Re: Umbrella Frameworks and headers
Re: Umbrella Frameworks and headers
- Subject: Re: Umbrella Frameworks and headers
- From: Bryan Pietrzak <email@hidden>
- Date: Mon, 12 Jul 2004 12:55:46 -0500
On Jul 12, 2004, at 12:18 PM, Nick Zitzmann wrote:
On Jul 12, 2004, at 9:08 AM, Bryan Pietrzak wrote:
If add an umbrella framework like ApplicationServices to my project
and then do an #include <ApplicationServices/ApplicationServices.h>
should I then be able to expect that ALL headers within the umbrella
framework, including those in sub-frameworks are available without
any additional effort in Xcode? If so, then the fact that PrintCore.h
does not include PMTicket.h is clearly a bug.
Most of them, anyway. Stuff that is needed for everyday use should be
part of the main header. The only other framework header I'm aware of
that isn't included in the master header is Foundation's NSDebug.h,
and I can understand why, because it's supposed to be used for
debugging purposes only...
So if PMTicket.h is supposed to be available for "everyday use", then
I would recommend filing a bug report on that. Chances are someone
overlooked that header when they were writing PrintCore.h, but there's
no way to be sure until a bug report is filed.
OK, thanks, I just filed a bug on this: rdar://3724777
If not, then I don't understand exactly what the Right Thing to do in
Xcode is with regard to these "orhpaned" headers within frameworks.
Is adding a sub-framework or adding a search path as above the Right
Thing?
I think adding the search path is the right way to do this right now.
I wouldn't make the project depend on an framework within another
framework's umbrella, since those could be moved around between OS
releases. I remember Metrowerks did this with MetroNub in CodeWarrior
Pro 6, which basically made it impossible to run the debugger in
versions of Mac OS X other than the public beta, because it depended
on CarbonCore.framework, and Apple moved that framework's location
from where it was in the public beta... Although a symbolic link could
probably fix that, how many of one's end users are going to figure
that one out?
Yeah, I'll go with the search path for now. Not ideal, but better than
the alternative.
Thanks
Bryan
_______________________________________________
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.