Quote:
Originally Posted by Adam B.
Most programs can't be easily modiifed to be location indemendant. When you compile them, you need to specify a directory prefix. If you do not put the program where it expects to be, it will not be able to load all of the shared files and libraries that it requires. Hence the need for a standard installation directory.
|
Actually you just set the prefix to "./" when you build them. Then they are
very location independent. This is why start.sh sets the cd when it starts (contentLister sets the cd to /).
I will also reset HOME in the start.sh for a few apps so I can keep more stuff inside the app's directory. Some apps will provide other environment variables that can be set to over ride where things go. Some times you actually need to take the time to read the app's manual when you set out to port it to the iLiad.
With the ability to pull out storage devices at will, I would highly advise against this approach of using a shared /usr/local. ipkg is going to be very perplexed if some Average Joe swaps out a storage device containing shared .so's and puts in a storage device that doesn't contain those .so's. ipkg doesn't grok removable media.
You also need to keep in mind that iRex doesn't have the storage devices setup in removable mode (they tried but alas didn't succeed). If you are installing ipk's on the iLiad itself the storage device is left in an inconsistent state after the installer is completed.
If you are a Unix head you know to do a sync before removing the storage device. Average Joe's though will run the shiny new app, confirm it works, then take the storage device back out to put files on it to use with the shiny new app. *poof* all hell breaks loose because the iLiad hasn't flushed all the changed data out onto the storage device before it was removed.
Unpacking the ZIP on their Mac/PC avoids this issue.
Yet another issue for Average Joe's is iRex's continuing problem with auto mounting storage devices. They turn on their iLiad, run to Starbucks for a coffee, come back and see it just finish booting. Then they click on the
The Forever War.rtf in Recent Documents and ... nothing. No error message, no ebook, just Recent Documents looking at them, or even more likely: a now
empty Recent Documents.
Your experienced iLiad Unix Head knows the @#$! CF card didn't automount so /mnt/cf/fbreader/FBReader isn't available for contentLister to launch to view the RTF file. Your Average Joe is left sucking on his coffee and wondering why he spent so much on this pile.
These are just highlights of why I packaged things as i did for Average Joe's to use. iRex barely knows what they are doing and won't listen to folks that
really do know what they are doing.
To support 3rd party development iRex needs to do more than simply release a compiler and some header files. They need to produce a reliable device that works more often than not and doesn't need to be repaired all the time.