devkitPPC r14 installer for Mac OS X, please test

[bushing]

I've been working on an installer package for devkitPPC on OS X; I'd appreciate it if anyone with a Mac could test it and give me some feedback.

It's available here:
http://s3.amazonaws.com/bushing/devkitP ... versal.dmg

It features:
* Universal binaries for 10.4+
* Xcode templates for Wii and GC
* Automagically sets up $DEVKITPRO / $DEVKITPPC

Roughly speaking, my steps in creating it were:
* Find two machines running 10.4 (ppc and i386)
* Built the toolchain separately on each
* Throw away everything from the PPC side that isn't an executable (or library)
* Merge the binaries together with lipo. (I tried a couple of scripts to do this and ended up just doing it by hand to make sure it went correctly)
* Install everything into /opt/devkitpro on my system
* Copy one of the system Xcode templates into "/Library/Application\ Support/Developer/Shared/Xcode/Project\ Templates/devkitPro/devkitPPC Wii Project/"
* Gut that example, replace it with the Wii template, add the Makefile to Xcode as an external build target, tweak slightly until working
* Write a little postflight script to handle the environment magic:

Code: Select all

#!/usr/bin/perl
$devkitppc = $ARGV[1];
$devkitpro = $devkitppc;
$devkitpro =~ s/\/devkitPPC//;

system "defaults write ~/.MacOSX/environment DEVKITPPC '$devkitppc'";
system "defaults write ~/.MacOSX/environment DEVKITPRO '$devkitpro'";
exit 0;

* Fire up PackageMaker.app, tell it to package everything up, tweak here and there
* Build package, convert to disk image

It should work on any 10.4 or 10.5 system, but I've only tested it on 10.5 with Xcode 3. Any feedback would be appreciated!

[melw]

Tried this on Intel Mac with OSX 10.4. Installer worked flawlessly, but there were few quirks I had to fix afterwards:

• Some previous devkitPro OSX installers (devkitARM r20 etc.) had copied the files by default under /opt/local/devkitPro, now the files went to /opt/devkitPro (although the latter directory is now used by other installers, too?)
• I had to manually export DEVKITPPC environment variable (other devkit* installers do this setting automatically for the user)
• I had to create a libogc directory myself and copy the include and lib directories there

But nevertheless I got this installed without any bigger problems and code compiling and working for Wii just in few minutes, thanks!

[bushing]

Tried this on Intel Mac with OSX 10.4. Installer worked flawlessly, but there were few quirks I had to fix afterwards:

• Some previous devkitPro OSX installers (devkitARM r20 etc.) had copied the files by default under /opt/local/devkitPro, now the files went to /opt/devkitPro (although the latter directory is now used by other installers, too?)

Yeah, WinterMute said on IRC that he thought we should switch to /opt/devkitpro.

• I had to manually export DEVKITPPC environment variable (other devkit* installers do this setting automatically for the user)

This is a bug. There is a postflight script that should handle this by setting keys in ~/.MacOSX/environment.plist. However, I just tried the installer on a new machine -- one without an environment.plist -- and that file got created as root, which could have caused the problem you saw. Can you check to see if you have a ~/.MacOSX/environment.plist, and if so, what are the permissions on it (and the directory ~/.MacOSX) ?

• I had to create a libogc directory myself and copy the include and lib directories there

This bug is easy to fix -- I'll fix it and re-roll the package once I've found a fix for the environment.plist problem. For reference, the script I'm running is:

Code: Select all

#!/usr/bin/perl
$devkitppc = $ARGV[1];
$devkitpro = $devkitppc;
$devkitpro =~ s/\/devkitPPC//;

system "defaults write ~/.MacOSX/environment DEVKITPPC '$devkitppc'";
system "defaults write ~/.MacOSX/environment DEVKITPRO '$devkitpro'";
exit 0;

The problem is that it's getting run as root...

[melw]

• I had to manually export DEVKITPPC environment variable (other devkit* installers do this setting automatically for the user)

This is a bug. There is a postflight script that should handle this by setting keys in ~/.MacOSX/environment.plist. However, I just tried the installer on a new machine -- one without an environment.plist -- and that file got created as root, which could have caused the problem you saw. Can you check to see if you have a ~/.MacOSX/environment.plist, and if so, what are the permissions on it (and the directory ~/.MacOSX) ?

Yep, as you suspected this file (and the directory) was created by root and the user I used to install didn't have access to it. Explains why I had to set environment variables manually.

[rabidsnail]

Xcode 2.4 doesn't like the project file. It says it can't parse it.

[Vexar]

Hello and thank you for your efforts so far!

I've installed XCode 3 on Mac OSX 10.5 (and I've never used XCode before, so this is fun).
I installed the disk image you created.
I opened XCode and started a new project, locating the devkitpro entry and selected a Wii project.

This produced a project with main.c and a makefile and the .dol and .elf targets.
The main.c had two includes ogcsys.h and gccore.h in it.
When I hit the build button, it produced 11 errors and 14 warnings, all of which stem from not finding the two aforementioned include files.
I found those files on the path created /opt/devkitpro/include and kinda just stared at them for a while.

I'm noticing an absent trailing end-quote on line 7 of your Makefile.
Also, your wii_rules references are slightly wrong. I executed the following commands:
cd /opt/devkitpro
sudo ln -s ./ libogc

And that worked fine for compiling.

These Integrated Development Environments sure are pretty, but it is the dickens to find things. The IDE colorizing the text sure helped find the one thing I spotted.

[Samson]

My private setup for Xcode has two differences:
- instead of putting DEVKITPPC and DEVKITPRO into the global environment, I set them in the environment for the external build target in Xcode
- I added an External Executable, that just runs make with the "reload" target, and the Makefile has a rule to upload/run the executable with psoload.
That way I can both run and build the game from inside Xcode, without going to the shell.

[Superior]

The download link doesn't work...