[GRASS-dev] Re: [GRASS GIS] #580: WinGRASS: $GISBASE/etc/gui/scripts/ require something like $(EXE) to run

[GRASS GIS]

#580: WinGRASS: $GISBASE/etc/gui/scripts/ require something like $(EXE) to run
---------------------------+------------------------------------------------
  Reporter:  hamish        |       Owner:  grass-dev at lists.osgeo.org
      Type:  defect        |      Status:  new                      
  Priority:  blocker       |   Milestone:  6.4.0                    
 Component:  wxGUI         |     Version:  6.4.0 RCs                
Resolution:                |    Keywords:  wingrass                 
  Platform:  MSWindows XP  |         Cpu:  Unspecified              
---------------------------+------------------------------------------------
Comment (by cnielsen):

 Replying to [comment:15 cmbarton]:
 > Why can't windows use g.gui gui=[guiplatform] -nu?

 This command does work in the msys command prompt (native installer
 r40049), with this followed by g.gui &, you can switch back and forth with
 no problem.

 >
 > In fact, even though both g.change.gui and v.type_wrapper are in my
 source, they are not getting into my OS X binary. Perhaps they are not
 getting into the Windows binary either?

 These are present in the windows installations in etc\gui\scripts. Well,
 in fact there is
 g.change.gui.py
 g.change.gui.sh
 g.change.gui.sh.bat
 but no
 g.change.gui

 >
 > There is a problem running python scripts in GRASS for Windows. Ironic
 in that one reason for Python is that it is cross-platform. From recent
 discussions on this (Glynn, Colin, me, others), it seems like the best
 solution will be to NOT package Python with GRASS (wxPython may be a
 different issue), but to have an installer that checks for a Python
 installation and if not present directs the user to python.org to install
 it. A regular Python installation will properly put Python in the registry
 so that it can be called to execute scripts.

 I've been working on an update to the NSIS installer that will check to
 see if Python is installed via the registry, and if not auto-download and
 install the four necessary packages (python, wxpython, pywin32, and
 numpy). The installer already does something similar for the sample
 datasets.

 However, if the gui or other modules needs a build specific version then
 this could get complicated... Is there a clear idea of which parts require
 build specific and which do not? Where do pywin32 and numpy fit in? Can
 build specific parts only be included in the installer and still use an
 external Python?

 I can make the installer, but I need these details to know how to assemble
 it.

 -Colin

-- 
Ticket URL: <https://trac.osgeo.org/grass/ticket/580#comment:16>
GRASS GIS <http://grass.osgeo.org>