So I've integrated TI's sgx package into the beaglebox build.  What this does is to run the SGX package's Makefile-based build which in turn installs a bunch of stuff from the archive into another directory.  This directory will then contain a bunch of files which need to be installed again, this time into the target root file system.

To do this post-installation step, the Imagination Technologies folks who provide the software for the PowerVR hardware, created an installation shell script.  The script offers options that allow it to run on the host or target platform.  But there is no way for it to work on the host platform for a cross-build system like BeagleBox because it assumes the host has the drivers you want on your target in its root file system.  A cross-build environment doesn't have this.  What's worse, the SGX build system (re: the build run before you run the install script) actually grabs *ALL* the drivers from your cross-built kernel tree and places it into its own tree as if the SGX build was your rootfs generator.  Wow.  Talk about clueless.  So the script has to be run on the target platform, the beagleboard.  And even then it installs everything under /usr/local/XSGX.  Yuck.  It's a mess.

The correct things to do for the SGX release would be:

• Provide a kernel drivers only package or build target that installs modules based on the standard modules build processes for modules built outside of the kernel tree.  Include a couple of make targets to generate stand alone modules.conf and modules.dep files and let integrators deal with integrating those with the target rootfs.
• Provide an X.org package or build target that does something similar for the X.org modules and config files.  These should be source code since they seem to provide very recent X.org drivers which are not necessarily compatible with build tools like buildroot's X.org package (though I've yet to test that).
• Provide a libraries and boot-script package or build target that allows installation into a user-specified root.  Honestly, the selection of the destination directory is not dependent on the hardware platform.  The distribution creator is responsible for that choice, and its usually based on the LSB or something similar.  This package can generate a boot script (or as many as needed)  based on which version of ES is selected, but the paths inside that script should be the same no matter which version is chosen.  For platforms that need more than one version, create an include file that sets a variable that points to the default ES version.  The include file can be sourced from the init scripts.  Locations for all these files are standard.

They could also make opkg's but then they would lock out distributions that don't use opkg.  BeagleBox will eventually support opkg, but doesn't yet.  It's better to provide the release files structured via the LSB definitions for where files go and let distribution creators determine how to package them.

I was going to rewrite the install script so it could be used in a cross-build environment, but the script has a builtin license clause that prevents modification and redistribution, effectively making their package useless in a clean distribution without a bunch of manual cleanup on the target on firstboot.  I don't know if any other distributions deal with this problem.  Robert Nelson provides the SGX stuff for ubuntu using the install.sh script for on-target installation.  I don't know yet what, if anything, the android and angstrom distributions are doing with respect to this problem.

Now we see the benefit of open source licensing.  If this license was more open, I could fix this for them.  But it isn't so I don't see why I would waste my time with it.  I can hack around their poor implementation on my build system, even if it is a bit ugly. How much nicer it would have been to be able to fix the problem and submit a patch.