[GRASS-dev] New OpenGL options to test for native Mac and Win NVIZ

[William Kyngesburye]

On Jul 20, 2006, at 10:18 AM, Paul Kelly wrote:

> On Thu, 20 Jul 2006, William Kyngesburye wrote:
>
>> On Jul 20, 2006, at 2:03 AM, Glynn Clements wrote:
>>
>>> There is a similar issue with the datum shift grids used by PROJ.
>> Oh damn!  I'm surprised noone has said anything from using my  
>> universal binaries (built on Intel Mac).  Maybe the datum grids  
>> are just not used much (it's only the extras for the states).  And  
>> here I was working on frameworks for my installers.  The PROJ  
>> framework would have the same problem as with the GRASS fonts, but  
>> I'm not sure I can do run-time processing in this case.
>
> This worked in GRASS 5.x. I didn't realise it was missing from the  
> install script for 6.x but I see now it is. I'm going away for the  
> weekend so won't have a chance to look at it until some time next  
> week but look at the 5.x install script to see how it is done:
> http://freegis.org/cgi-bin/viewcvs.cgi/*checkout*/grass/ 
> binaryInstall.src?content-type=text/plain
> (search for nad2bin - probably something similar can be done for  
> the fonts).
>
I've never used this.  I take it this would start with something like  
'make dist' to package it all up, including the raw datum files?   
Then you run the script when you want to install it on another  
machine?  I'm currently doing a normal install, then archiving the  
installed folder + the grass61 and gem programs, this works better  
for a Mac installer package than the script.

The script would work fine for a unix-style install, since the user  
must use the script to install it, and its destination is fixed by  
the build configuration.  But an OSX Universal .app is a different  
matter.  Usually drag-n-drop, but it can use an installer,  
destination is not fixed, though normally it's /Applications.  So a  
drag-n-drop install can't take care of platform-specific (PPC/Intel)  
files at install and would have to do it at runtime.

And, I was thinking of the libproj datum files, but I see that GRASS  
has it's own copy.  So, why the duplication?  Why not just use the  
libproj files in-place, or symlink the proj data folder?

> Is there any particular reason why installable Mac binaries  
> couldn't run an install script? It would seem like a pretty common  
> thing to want to do :/
>
A program could.  MS Office does it to install support files on the  
first run (no quite a script, but same idea).  I think Lorenzo's  
grass.app does to start GRASS, maybe setting env vars.  But it  
wouldn't really work for a library, the calling application would  
have to do it, or set an environment variable (ie PROJ_LIB to point  
to the correct PPC/Intel copy of the datum files).

-----
William Kyngesburye <kyngchaos at kyngchaos.com>
http://www.kyngchaos.com/

All generalizations are dangerous, even this one.