2009-01-18, 07:43
davilla Wrote:Here's an example. LibSDL and friends is a lib that XBMC uses. MacPorts also has that lib. The current XCode project links to static libs (.a) in /xbmc/libs/libSDL-OSX. While MacPorts does have SDL, it does not have the xbmc specific patches. The SDL in MacPorts will work but there will be small problems here and there.
Yeah, I realize that "problem"... frankly that was (IMO) a bad design decision early on. Those patches should've been pushed back to developers or the XBMC "wrapping" should've been a small bit of code that interfaced between SDL and XBMC. The XBMC svn repo contains copies of 10s of other opensource projects (rather than just maintaining necessary patches for those other projects and filing bug reports with the maintainers of your dependencies)
Quote:The current XCode project does not build these SDL static libs, they exist as binaries in svn.
Ugg... even worse. I didn't realize that.
Quote: There is a build script (buildSDL-osx.sh) that builds them but it's a manual process. We don't like binaries in svn and even more, dislike binaries in svn that don't have their build documented. That's why I added buildSDL-osx.sh as a stop gap measure to document the buiid. There's lots of "build-osx.sh" scripts scattered around. These are present to document the builds of most those binaries in svn. Yes, it's a hack but it's much, much better than a binary in svn that no one knows how to build because the dev who built it left the project.
Well, I'm glad that is being addressed.
Quote:The proper way to handle these SDL static libs is to included them in the configure/make, then have the Xcode project run something like "make libSDL" when building to create/check them. That way they stay up to date.
There are about 20 libs that the XBMC binary uses. A few are built by run scripts in Xcode, the others rely on binaries in svn.
Yes, there are several things very wrong with the current OSX build. I'm working on rectifying that situation but it takes time and effort. I inherited it from the previous XBMC for OSX devs who a) did not understand configure/make and b) did not understand Xcode. While what they did resulting in being able to build XBMC for Mac, it's a mess and hard to maintenance and almost impossible for anyone else but an expert to completely rebuild from scratch.
Yeah, I understand that... and I'm certainly willing to help where I can... I'm good with autoconf, but lousy with XCode.
What I DO want is to figure out what libs we can avoid building from svn and instead use existing libs. For the ones that we can't do that for, I want to understand why and try to get the necessary changes accepted into upstream or atleast into Macports, so we CAN use them instead of what is in SVN. That will make the effort of going to ppc much more manageable since it will be multiple smaller tasks rather than one large task.
Actually runs too. I might take you up on the autoconf help, I was stuck in autoconf hell two days ago.
