> On Oct 13, 2015, at 3:28 PM, John Daniel <[email protected]> > wrote: > > I wasn’t talking about what might or might not be documented. In “Anatomy of > Framework Bundles”, Apple documents how the bundle should look and how > multiple versions should be used. I don’t know how your framework looks. Does > it have a “Current” link and does it point to “M”? I can see how it might > look for other versions and attempt to sign them. In general, my point is > that it is usually a bad idea to be the only person exercising a particular > feature. You ship against released operating systems, not documentation. > Worry about what they do, not what they are, or were, supposed to do. > > Also, it doesn’t sound like you have your workspace setup correctly. I > strongly suggest that your workspace be completely self-contained. The > workspace should be the one building your framework. The only exception might > be external, multi-platform, multi-architecture static libraries. I’m not > sure if even that approach will be viable for the future. Let Xcode build it > all and sort it all out.
You are making a great many unhelpful and, I must say, unfounded assumptions. All I want to know is whether there is some way in Xcode 7 to specify a framework version other than "A" when codesigning an embedded framework from the target's General tab at build time. I didn't specify the rest of my setup in detail because I'm not asking about anything else. For the record, my framework does look like the frameworks you're describing, complete with a "Current" link pointing to "M", because that's the way frameworks are supposed to be arranged. That has been well documented for many, many years. I have been distributing my framework for 13 years in that form (but using different version letters) with many satisfied application customers and several well-known corporate licensees of my framework used in popular commercial products. We all agree that it is necessary to worry about what our software does -- that's why we test it. But despite Apple's sorry record with respect to documentation in recent years, I am a firm believer in up-to-date, complete and accurate developer documentation. It not only helps to avoid the time wasted and mistakes made by trial-and-error programming, but if done right it provides assurance that one is doing things the way the developer intended. Also, I am certainly not the only person using multiple versions or versions labeled other than "A" in shared frameworks. That, too, has been part of my routine and used successfully by my customers for many years and well documented since the beginning. I just now examined the many frameworks installed in the standard shared location, /Library/Frameworks/, on one of my Macs. The Adobe Air framework uses a single version but labels it "1.0" instead of "A". The HPPml framework uses a single version but labels it "B" -- so there's another example of not using "A" but instead doing it the same way I do in my embedded framework. Ditto the HPServicesInterface framework. Apple's PluginManager framework contains two versions labeled "A" and "B" -- so that disproves your assumption that Apple always uses only one and always labels it "A". Also, I do have my workspace set up correctly. It is completely self-contained, containing both the framework project and the application project. The framework is linked into the application, and I have confirmed that the workspace builds the release and not the debug version of the framework into the built application. Neverthelss, I believe you are mistaken in asserting that frameworks should never be built separately. I believe they should always be built separately first -- that is the way I have done it for 13 years. Once you've reached a certain point it is useful to add a test application or two to the workspace. But once a framework is completed, I know from long experience that it works perfectly well to build additional application products by putting the built framework into the standard shared framework location or a special location noted in your application's build settings and leaving it out of the workspace, and it also works to put the built framework into the application workspace or project with its headers but without its source code. Many developers never even get their hands on a third-party framework's source code and can't include that in their application workspace. So, let me be perfectly clear about my question: Is there some way in Xcode 7 to specify a framework version other than "A" when codesigning an embedded framework from the target's General tab at build time? If so, what is it? If anybody knows of any documentation, please refer me to it. Thanks. -- Bill Cheeseman - [email protected]
_______________________________________________ Do not post admin requests to the list. They will be ignored. Xcode-users mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/xcode-users/archive%40mail-archive.com This email sent to [email protected]
