[jeremyhu]

I can't recall which thread this was in, so I figured I'd start a new one properly titled for this topic...

If you want to build binaries distributable to 10.4 from your 10.5 box you should do the following.

1) Set the +universal variant in /opt/local/etc/macports/variants.conf
2) Choose the 10.4u SDK in /opt/local/etc/macports/macports.conf by adding these lines:

Code:

universal_sysroot /Developer/SDKs/MacOSX10.4u.sdk
universal_target 10.4

I previously forgot the universal_target line in the earlier thread but couldn't find it to make the correction.

Note that this will need to be done before building anything in Macports. You may also need to change the x11 prefix to be more 10.4 friendly if you plan to build X11 binaries:

Code:

x11prefix /usr/X11R6

[n9mjg]

So with the target set to 10.4 would this then be redistributable to the apple tv?

[davilla]

So with the target set to 10.4 would this then be redistributable to the apple tv?

yes, it should. I've not tested this myself yet but will be doing so shortly as this resolves build issues with using MacPorts as a dependency. That being building on 10.5 and running under 10.4.

[Gamester17]

If this work out smoothly, could/should the instructions be added to the wiki and to the SVN readme?
http://wiki.xbmc.org/?title=HOW-TO_compi...ource_code
http://xbmc.svn.sourceforge.net/viewvc/*...README.osx

[davilla]

If this work out smoothly, could/should the instructions be added to the wiki and to the SVN readme?
http://wiki.xbmc.org/?title=HOW-TO_compi...ource_code
http://xbmc.svn.sourceforge.net/viewvc/*...README.osx

yes, that was the plan

[jeremyhu]

The "if this works out smoothly" is the crucial part. If it doesn't work, then it is a bug with MacPorts, and I'll work to get that addressed.

Also, as of a few days ago, the version of Samba in MacPorts should work (meaning we don't need to pull in the older 3.0.x version). Unfortunately my main dev box crapped out on me yesterday before I had a chance to really test out the XBMC build from MacPorts, but it atleast ran for whatever that's worth

We could possibly even update the list of ports to install to just 'XBMC' and note that it will pull in all requirements and install a MacPorts built XBMC.app in /Applications/MacPorts

[davilla]

The "if this works out smoothly" is the crucial part. If it doesn't work, then it is a bug with MacPorts, and I'll work to get that addressed.

Also, as of a few days ago, the version of Samba in MacPorts should work (meaning we don't need to pull in the older 3.0.x version). Unfortunately my main dev box crapped out on me yesterday before I had a chance to really test out the XBMC build from MacPorts, but it atleast ran for whatever that's worth

We could possibly even update the list of ports to install to just 'XBMC' and note that it will pull in all requirements and install a MacPorts built XBMC.app in /Applications/MacPorts

cool, just and FYI, a command-line configure/make for OSX is in progress. It's progressing smoothly and should (god willing and the creek don't rise) get pushed back into SVN by this weekend.

[tvont]

is it already possible to use macports 1.7? And a pure 10.5 app?

[davilla]

is it already possible to use macports 1.7? And a pure 10.5 app?

macports 1.7, that's what the man says

"a pure 10.5 app" -> I have no clue what this means. XBMC built under 10.5 or 10.4 is not going to make it run any faster/better or worse. Mind that to be fully build on 10.5 you will need to rebuild ALL the libs. The XCode project only build about 20 percent of the libs which is why I'm spending time on getting the configure/make working.

[tvont]

davilla, thanks. my question was malformed, sorry (was really tired yesterday :-)). I meant, to use the 10.5 SDK . You say, by using 10.5 SDK within xcode, only 20% of the libs are beeing built currently?

[davilla]

davilla, thanks. my question was malformed, sorry (was really tired yesterday :-)). I meant, to use the 10.5 SDK . You say, by using 10.5 SDK within xcode, only 20% of the libs are beeing built currently?

All the libs are build correctly except MADDLL. What is not considered is if 10.5 or 10.4 sdk is used. Again, this does not matter running under 10.5 but under 10.4. There is no gain to build to 10.5sdk. It does not matter. There's no speed up/slow down, etc. Don't worry about it for now.

XBMC for Mac is a combination of the main binary (XBMC) along with codec and libs (both internal and dynamically loaded). If you look at the XCode project, the build libraries target only builds the internal libs using a call to run various bash scripts. These scripts are forced 10.4sdk. Plus python and ffmpeg are also forced 10.4sdk. And the codec building is run manually using scripts or some unknown process.

I started adding libs to the build libraries target but that quickly became unmanageable because the build had to do both configure/make which took time to run, this lead to creation of the manual build scripts and this lead to the current effort which is to fix the main configure/make to build everything correctly (either 10.5 or 10.4 sdk) and then mod the XCode project to leverage this functionality.

[jeremyhu]

davilla, thanks. my question was malformed, sorry (was really tired yesterday :-)). I meant, to use the 10.5 SDK . You say, by using 10.5 SDK within xcode, only 20% of the libs are beeing built currently?

In my testing, I forced the 10.5 SDK and it built/ran fine. You'd just need to set -sdk and MACOSX_DEPLOYMENT_TARGET on the command line. I'm sure there are some places that gets overwritten (but it shouldn't) in some of the build scripts...

[jeremyhu]

the current effort which is to fix the main configure/make to build everything correctly (either 10.5 or 10.4 sdk) and then mod the XCode project to leverage this functionality.

By "everything", do you mean both internal and external libs that we don't really need to build? If so, then I'd say that is wrong. If you want to allow someone to build libXXXX at the same time as XBMC, great, but make that a configure option and not by default. We'd much rather update libXXXX independently of XBMC and not have a separate version of it just for XBMC (I realize some libs need to be that way due to some wrapping you guys are doing, but that should be the exception rather than the rule)

[davilla]

By "everything", do you mean both internal and external libs that we don't really need to build? If so, then I'd say that is wrong. If you want to allow someone to build libXXXX at the same time as XBMC, great, but make that a configure option and not by default. We'd much rather update libXXXX independently of XBMC and not have a separate version of it just for XBMC (I realize some libs need to be that way due to some wrapping you guys are doing, but that should be the exception rather than the rule)

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.

The current XCode project does not build these SDL static libs, they exist as binaries in svn. 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.

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.

[jeremyhu]

... nothing to see here...