> On 16 Oct 2015, at 16:33, Bill Cheeseman <[email protected]> wrote:
>
> However, when a framwork isn't finished or isn't fully tested, it makes sense
> to place the framework project and the application project in a single
> workspace so you can edit, debug and build both of them together. It is very
> helpful to be able to single-step from application code into framework code
> and back out again. That's what I'm doing now.
It’s very easy in these email discussions to be at cross-purposes, so let me
check that we’re on the same wavelength. My setup looks like this:
Workspace
App project
main app target
other targets
Framework-1 project
main fw-1 target
other targets
Framework-2 project
main fw-2 target
other targets
and so on…
Is this what you’re doing or is it something different?
In my experiment, I select the “main fw-1” target, and in its build settings,
under “Packaging”, there is “Framework version”, which defaults to “A”. If I
change that to (say) “M”, and rebuild, Xcode generates a new version “M”,
merges it into the f/w bundle and the whole thing gets copied to the app’s
bundle eventually (via a step in the app’s target’s build phases.) For release
builds, it’s version ‘M’ that is signed (you can see it in the build
transcript). Does it not do that for you?
One thing I noticed is that with the above steps, Xcode doesn’t update the
“Current” symlink in the framework bundle. That still points to the older
version, so if you were now to sign the built f/w from the CLI, it would sign
the old version, not the new one (ie ‘A’ and not ‘M’ in the above example).
Regards
Sak Wathanasin
_______________________________________________
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]
