|
|
Framework tutorial
|
|
|
|
Mac Elite
Join Date: Sep 2000
Location: Edmond, OK USA
Status:
Offline
|
|
Can someone recommend a good tutorial for building custom frameworks? I tried just using the template in XCode, but it gave me a framework that can only be run by the user that created it (when I copied it to another account and ran the executable it complained about links to the original users' directories, even though the framework was completely empty [New Framework -> Build]). Oddly enough, when I copied the executable from another framework into mine (Stuffit.framework) it worked just fine.
On a side note, this forum is pretty dang slow. Does anyone have any recommendations for more active OS X development forums?
|
|
|
|
|
|
|
|
|
Professional Poster
Join Date: Sep 2000
Location: Texas
Status:
Offline
|
|
www.idevgames.com is a great Mac programming forum. They are nice and fast with answers. Also, there is a large archive of tutorials and links to tutorials. But.... it isnt up right now.
|
|
|
|
|
|
|
|
|
Mac Elite
Join Date: Dec 2001
Location: Atlanta, GA, USA
Status:
Offline
|
|
With Mach-O you have to link to the framework in its actual path, unlike PEF, which can use relative paths.
There was a big discussion about this on the RealBasic betas list a month or so back.
|
Mac Pro 2x 2.66 GHz Dual core, Apple TV 160GB, two Windows XP PCs
|
|
|
|
|
|
|
|
Mac Elite
Join Date: Sep 2000
Location: Edmond, OK USA
Status:
Offline
|
|
Originally posted by Arkham_c:
With Mach-O you have to link to the framework in its actual path, unlike PEF, which can use relative paths.
There was a big discussion about this on the RealBasic betas list a month or so back.
That seems kind of lame. Why would Apple release a technology that was so inflexible?
Do you have a link to that discussion?
|
|
|
|
|
|
|
|
|
Addicted to MacNN
Join Date: Mar 2000
Location: London, UK
Status:
Offline
|
|
This isn't entirely true. There's a linker hack which lets you have a relative path to the application executable (@executable_path/../Frameworks/Blah).
|
|
|
|
|
|
|
|
|
Mac Elite
Join Date: Sep 2000
Location: Edmond, OK USA
Status:
Offline
|
|
Originally posted by Angus_D:
This isn't entirely true. There's a linker hack which lets you have a relative path to the application executable (@executable_path/../Frameworks/Blah).
That's my point. By default, the linker uses a hardcoded path, but there is a hack to allow for the correct behavior, which is to make a relocatable framework within the application. The default behavior should be to use a search path to find frameworks, from within the bundle to the user's library/frameworks to /Library/Frameworks to System/Library/Frameworks. At the least it should be possible to link to a framework in a more flexible manner.
With that said, I found my problem. I didn't realize two things:
1 - I had left an old copy of a failed attempt to create the framework in a directory, and I had added that framework to the project at one point (even though I had subsequently deleted it from the project).
2 - XCode uses a search path for frameworks, so when a new one is added to the project, XCode stores a reference to the containing directory in the search path and adds the framework name to the project.
To make a short story long, no matter how many times I deleted and re-added the framework it would always use the oldest one since it came first in the search path. This little annoyance has cost me 4 days of lost time, but at least I am on track now.
I still don't understand that with the flexibility that shared libraries had on OS 9, and a system built on the concept of search paths, etc, that Apple would have implemented frameworks in this way (not talking about XCode now, but the system).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Forum Rules
|
|
|
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
|
HTML code is Off
|
|
|
|
|
|
|
|
|
|
|
|