Framework #import issues

I can't figure out how to build from a github pull
So I'm pretty new to Xcode development, ton of experience with "normal" unix build tools like gcc, git, etc.

I can't tell which branch is "current" in elan's github repo. Looks like there's a fairly active xbmc branch but that's just tracking upstream, and has no plex stuff in it. v0.8 has no commits since May. So anyway, I pulled v0.8 and try to build. fail.

After some cleanups:


a2fa233 : 2009-08-07 09:38:24 -0700 : Craig R. Hughes : Fix permissions<br />
c4accfb : 2009-08-04 15:04:52 -0700 : Craig R. Hughes : Fix line endings<br />
236aae5 : 2009-08-04 14:22:28 -0700 : Craig R. Hughes : Fix signing thing in some other configuration thing<br />
e41c83b : 2009-08-04 14:18:13 -0700 : Craig R. Hughes : Fix XCode library paths



(That's basically mostly adapting to new libs in macports vs the xcode project file like libbz2 and a problem with ^M and file permissions on build-number.py)

I know *almost* can build. But the two frameworks BWToolkit and Sparkle seem to not be working right. Specifically:


In file included from /Users/craig/code/plex/xbmc/osx/CocoaUtils.m:33:<br />
/Users/craig/code/plex/xbmc/osx/SUPlexUpdater.h:10:28: error: Sparkle/Sparkle.h: No such file or directory



and


In file included from /Users/craig/code/plex/xbmc/osx/AdvancedSettingsController.m:9:<br />
/Users/craig/code/plex/xbmc/osx/AdvancedSettingsController.h:10:51: error: BWToolkitFramework/BWSelectableToolbar.h: No such file or directory



The frameworks are there, not red in XCode, etc. but for some reason XCode is magically failing to find the header files when they're #imported. If this were a #include thing, I'd know how to get gcc to -I/some/path to get them picked up; but I know not what the magic of Frameworks and #import is. How do I get XCode to find the headers?

Thanks for any help, I'm looking forward to hacking on this thing a little; great app. Patch files for the 4 changes I made above attached, in case I did something dumb in there in my naïvety.

Hi Craig, welcome to the forums, and impressive simultaneous use of baby, phone, and computer :slight_smile:



We don’t generally push out work in progress for a current release, so the v0.8 branch on Github is the latest for now. However, as soon as later today we’ll be releasing 0.8.2 and pushing new source out.



I’m not entirely sure why you’re having those issues, usually we see things like that if people try to build the wrong branch (i.e. master instead of v0.8), but that doesn’t seem to be the case. Have you tried building both debug and release? And what version of XCode are you using?

Welcome from me too :slight_smile:



The only thing that strikes me as odd is the “Fix Xcode library paths” in your list of cleanups. I’ve recently set up a build environment on a new Mac, and I never had to modify any permissions or library paths in Xcode to get Plex to build. What did you have to change, and why?

Maybe I’ll wait till 0.8.2, that might just magically fix it; I suspect the problem to some degree is bitrot.



That “path changes” I fixed were finding targets to match up against some of the libraries in the project; for example v0.8 wants to link against libbz2.1.0.4.dylib, but ports is up to 1.0.5 now, so I just changed that to be libbz2.1.dylib instead. I turned off code-signing since I don’t have the Plex signing key. And I did this:



-			   EFF082090E106C00004114E6 /* SmartCrashReportsAPI.o */ = {isa = PBXFileReference; lastKnownFileType = "compiled.mach-o.objfile"; name = SmartCrashReportsAPI.o; path = xbmc/lib/libSmartCrashReports/SmartCrashReportsAPI.o; sourceTree = "<group>"; };<br />
-			   EFF0820A0E106C00004114E6 /* SmartCrashReportsInstall.o */ = {isa = PBXFileReference; lastKnownFileType = "compiled.mach-o.objfile"; name = SmartCrashReportsInstall.o; path = xbmc/lib/libSmartCrashReports/SmartCrashReportsInstall.o; sourceTree = "<group>"; };<br />
+			   EFF082090E106C00004114E6 /* SmartCrashReportsAPI.o */ = {isa = PBXFileReference; lastKnownFileType = "compiled.mach-o.objfile"; name = SmartCrashReportsAPI.o; path = plex/CrashReporterHelper/SmartCrashReportsAPI.o; sourceTree = "<group>"; };<br />
+			   EFF0820A0E106C00004114E6 /* SmartCrashReportsInstall.o */ = {isa = PBXFileReference; lastKnownFileType = "compiled.mach-o.objfile"; name = SmartCrashReportsInstall.o; path = plex/CrashReporterHelper/SmartCrashReportsInstall.o; sourceTree = "<group>"; };



because SmartCrashReportsAPI.o was red, since it's missing in the xbmc/lib/libSmartCrashReports directory (the Install one is there), so I did a search and found both files in the plex/CrashReportHelper directory so linked to those instead. So the libbz2 thing should work as I've changed it, and the missing SmartCrashReportsAPI.o seems kinda weird -- both that the project file tries to link to a thing which isn't in GIT and that that library is apparently in 2 different places in different parts of the tree. But I'm not getting errors on either of those after my resolutions there, just on the BWToolkit and Sparkle framework #import lines.


I was trying to build Release (hence the code signing turn off stuff); I'll try a Debug build now; I can't imagine it'd change anything unless there are build steps in the Debug build which aren't in the Release build that magically make the imports work? Maybe I should read an OSX devtools manual or something and try and figure out where XCode tries to look when it sees a #import

Yup, as expected, Debug build gives identical errors in the same places. Can’t find the two frameworks’ header files.

Aha! For some reason, my GIT checked out what should have been symlinks as text files instead:



[craig@puck:~/code/plex/plex/Frameworks/Sparkle.framework]$ file *<br />
Headers:   ASCII text, with no line terminators<br />
Resources: ASCII text, with no line terminators<br />
Sparkle:   ASCII text, with no line terminators<br />
Versions:  directory



I deleted the text files, stuck in symlinks to the right places, and now it's working.

Something had set my git config core.symlinks to false, system-wide. How weird.

Thanks for posting the solution, I was really scratching my head over that one :slight_smile:



Glad to hear you’re up and running!

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.