Using the framework inside an Xcode project

[DamienSirkis]

I'm wondering how people are integrating the sparkle framework inside their projects. Basically I'm assuming I must be doing it wrong and wanted to sanity check.

I use a git submodules to bring the Sparkle master branch in to a sub directory of my project. I then add sparkle.framework as an entry in the 'Linked Frameworks and Libraries' and also as a item in my copy phase for frameworks (which copies into the Frameworks directory of my app bundle).

This works great until install time. I can't build a release version without a) changing the install path in the Sparkle project from @rpath to @executable_path/../Frameworks b) turning on 'Skip Install' to avoid a warning (using the install path with @executable_path but with 'Skip Install' off.

I'm assuming the project must build as a useable framework right out of the box for others so I'm wondering where I'm going wrong in setting this up.

[jakepetroules]

Looks like you're having the same issue as in #420 - see my answer there.

[DamienSirkis]

This works for setting the install path but building a release version (archiving) of my app still creates a multi-target bundle with my executable and a copy of the framework in /Library/Frameworks unless I set 'Skip Install' to ON in the sparkle project.

[jakepetroules]

Some people skip install, others don't (see #409). Not all the defaults will work for all users - is there a reason simply changing SKIP_INSTALL to YES is a bad solution for you?

[DamienSirkis]

Only reason is that it creates a un-committed changes in a repo I can't commit to. I'm kinda OCD about stuff like that.

I could fork but then I'd have some extra steps in order to get latest changes, at least in the way I understand git works.

[jakepetroules]

You could possibly look into Git subtrees to better handle this.

@pornel Any thoughts?

[DamienSirkis]

I have to admit my git-fu is not up to part yet so my apologies if I'm missing something simple. I use submodules right now for all my externals.

[jakepetroules]

Personally, I wouldn't recommend submodules for external dependencies; I find that git subtrees tend to be better solutions in that case. To each their own though.

[kornelski]

To me subtree is even worse pain than git submodules. In my own projects I use a Makefile that downloads the tarball, but that's not so great either.

It'd be nice if we could figure out a way to make Sparkle usable as a submodule.

[DamienSirkis]

I take it that cocoa pods doesn't solve all of this either, right?

[jakepetroules]

@pornel I think it's fairly impossible to do so given that (IIRC) Xcode projects can't inherit settings from a workspace.

[kornelski]

How do others solve it? Surely, Sparkle isn't the only framework around.

[DamienSirkis]

For info, I have the same problem in other frameworks too. @jakepetroules might be right in that there isn't a clean way of doing it.

Let me play with what I have and report if I find anything that could work.

[DamienSirkis]

Getting closer. I tried setting the install dir to $(DYLIB_INSTALL_NAME_BASE) which would let the install overwrite the embedded frameworks but work with everyone's config. This works but generates one warning because using the embedded path sort of implies 'Skip Install'.

What would you guys think of creating a separate target? "Sparkle Embedded" that would have the options needed for embedded frameworks. That seems like the cleanest to me, downside being some option might need to be maintained in two places.

[jakepetroules]

I don't think that is a good idea. Options are designed to be set, which is why we have several build options to change how Sparkle is built.

We could maybe add a build setting, SPARKLE_FRAMEWORK_SKIP_INSTALL but beyond that, it's the user's responsibility to configure a setting like this. Can CocoaPods apply build settings to external projects?

[DamienSirkis]

I don't disagree. The issue here is that, as far as I can see, the only way to configure this is by modifying a committed file. Ideally this should be inherited from the top level project.

[DamienSirkis]

I don't see a solution without being able to set INSTALL_DIR or SKIP_INSTALL from the parent project, which doesn't seem possible, or create separate targets with different settings.

As it stands, INSTALL_DIR is always set to /Library/Frameworks and SKIP_INSTALL is off so Xcode is doing the right thing and installing the framework (as in, a second copy of it on top of the embedded one copied during the copy phase) in the final archive.

Still trying to scour the net for other examples of this, I have the same issue with tag lib and FMDB but people just seem to modify the Xcode project.

[tonyarnold]

I read through #409 — wow, what a nasty vibe in that issue!

Under what circumstances would Sparkle ever need to be installed in /Library/Frameworks? Shouldn't the project be configured for how Sparkle is going to be used by the majority of users?

IMO Sparkle should be set to SKIP_INSTALL=YES at a minimum for Release builds, as it is not currently working for anyone who uses Xcode Archives.

[DamienSirkis]

For what it's worth, I switched to using cocoapods. It doesn't let me use the bleeding edge version on github anymore since it can only use packaged releases but it sorts out the whole SKIP_INSTALL problem.

[tonyarnold]

CocoaPods isn't an option for my project. This issue isn't resolved for me.

[kainjow]

My two cents: I use Sparkle by adding it to the project as described but I don't use Xcode's archive feature at all, so this hasn't been an issue for me.

[DamienSirkis]

I'll reopen it so that the maintainers can decide one way or the other.

My findings were that there is no way to override or inherit SKIP_INSTALL from a workspace in Xcode. That means that whatever setting the Sparkle project has can't be changed by another project including it. Feel free to correct me on this if I'm mistaken.

In light of this, I would tend to agree with @tonyarnold. I don't see many reasons why this would be set to NO by default for the vast majority of cases.

Maybe @jeremyhu could chime in an explain why he needs it set to NO. Looking at the issue he started, I'm still not quite sure what he's trying to achieve.

[jeremyhu]

SKIP_INSTALL can certainly be overwritten. You can overwrite whatever build settings you want for each project in the workspace by editing your workspace's schemes.

My use case for it being set to YES is that the app that I'm bundling it into is built from an alternative build system, so I first build and install Sparkle with:

xcodebuild -project Sparkle.xcodeproj -configuration Release ARCHS='...' SDKROOT='...' DSTROOT='...' INSTALL_PATH='.../XQuartz.app/Contents/Frameworks' SKIP_INSTALL=NO install

I then build XQuartz.app linking against the staged Sparkle.framework

[DamienSirkis]

I stand corrected if it can be overwritten but when I tried to do that (dropping the sparkle xcodeproj inside my workspace) I was never able to override the setting inside Sparkle's project. Would love to see an example of this.

Regarding the install part, why not grab the built framework directly from the build directory instead of installing it then copying from the install location?

[jeremyhu]

I'm not copying it from the install location. I'm using DSTROOT to set the path to my staging destroot, so xcodebuild install properly roots it within that location (similar to DESTDIR in autoconf). There's no need for a secondary copy.

And regarding examples of how to use schemes, we had a few good sessions at WWDC, and you can download the videos from the ADC website (I think even free ADC accounts have access to the videos).

Also, there is some documentation here:
https://developer.apple.com/library/ios/recipes/xcode_help-scheme_editor/Articles/SchemeDialog.html#//apple_ref/doc/uid/TP40010402-CH1-SW1

[DamienSirkis]

That makes sense on the copying part.

So basically no matter what the setting is in the project, we could both override it to fit whatever case we have (you from the command line and us from the Xcode schemes), correct?

[tonyarnold]

How do schemes let me override build settings in a sub project without modifying the sub project? I couldn't seem to override build settings from the scheme unless they were already present in the sub project.

[kornelski]

Would it help if Sparkle had different configurations such as "Release—with install" and "Release—without install"?

[jeremyhu]

Yes, either way, it's just a build setting that can be changed. I filed my ticket because I noticed the change to SKIP_INSTALL=YES when it broke my build, and I suspect the originator of this ticket similarly filed it because SKIP_INSTALL=NO broke their build in the opposite way. Unfortunately the history of the project has both options used at different times, and neither is technically correct, so the one that is used should really just be the one that works for more people, and others can just set it on their end.

Regarding schemes and build settings, I seem to have misremembered. Sorry for misleading you. I thought for certain it was possible, but I can't see the option to do so. There are certainly options to set overrides for environment variables, command line arguments, and other runtime options in the run and test sections of the scheme, and the developer has the option of overriding the build configuration used, but the ability to set an override for a build setting seems to not be there (unless I'm just somehow missing it in the UI). FWIW, I just filed a radar for that, so hopefully it'll appear eventually.

I'm not a big fan of build configuration bloat, and given that SKIP_INSTALL=NO is only really useful in the presence of an INSTALL_PATH build setting, I don't think the "Release - with install" configuration will have much benefit because the developer will still need to set INSTALL_PATH to a location within their app bundle.

As SKIP_INSTALL=YES is more beneficial for users and anyone wanting SKIP_INSTALL=NO already needs to have solved the "how do I set build settings?" problem for INSTALL_PATH, it seems prudent to make the build settings at work for developers like the reporter by reverting the revert (ie, going back to SKIP_INSTALL=YES).

[vslavik]

I'm not a big fan of build configuration bloat, and given that SKIP_INSTALL=NO is only really useful in the presence of an INSTALL_PATH build setting, I don't think the "Release - with install" configuration will have much benefit because the developer will still need to set INSTALL_PATH to a location within their app bundle.

This is not true. You can — and I’d say it’s a typical use of Sparkle — copy Sparkle.framework in a copy phase of the build into the appropriate location; this does not require setting INSTALL_PATH or doing any other modifications to Sparkle project (i.e. the git submodule can be clean). The problem is when archiving, which installs everything that doesn’t have SKIP_INSTALL=YES in addition to the app copying Sparkle.framework to its own bundle. It’s a separate step that Xcode performs and that the user has no control over.

I’d like to add my voice to @tonyarnold here — the current state with SKIP_INSTALL=NO makes Sparkle unusable with Xcode archiving and there’s no way to change the behavior from the containing workspace. The only fix is to maintain my own fork of Sparkle with just this change (as @tonyarnold had to do and as I will have to now) instead of simply using upstream as a submodule.

I too think that compatibility with the default/standard/recommended way of building releases is more important than compat with old scripts (FWIW, when I updated Sparkle, it too broke some of my custom resigning stuff, so I updated my script — comes with the territory).

[jeremyhu]

@vslavik You said "This is not true" ... can you please elaborate? Your statement does not contradict mine in any way, and I'm 100% in agreement with you (other than your claim that my statement is untrue).

[vslavik]

can you please elaborate?

I’m so sorry, you’re completely right — I managed to spectacularly misread your comment :-(