[GRASS-dev] [GRASS GIS] #1819: problems compiling map swipe, animation, modeler, and r.li.setup

[GRASS GIS]

#1819: problems compiling map swipe, animation, modeler, and r.li.setup
-----------------------------+----------------------------------------------
 Reporter:  cmbarton         |       Owner:  grass-dev@…              
     Type:  defect           |      Status:  new                      
 Priority:  normal           |   Milestone:  7.0.0                    
Component:  wxGUI            |     Version:  svn-trunk                
 Keywords:  g.gui.* modules  |    Platform:  MacOSX                   
      Cpu:  OSX/Intel        |  
-----------------------------+----------------------------------------------

Comment(by cmbarton):

 Replying to [comment:15 wenzeslaus]:
 > Replying to [comment:14 cmbarton]:
 > > Which items are fixed in  r64677? I can recompile on Thursday but need
 to know what to look for.
 >
 > `toolboxes.py` is called (as a script) during compilation to build the
 XMLs for toolboxes. `toolboxes.py` before r64677 required wxPython even
 when executed as a script. The environment to run GRASS modules (and
 `toolboxes.py` script) during compilation is somehow incomplete. The wrong
 environment cases wrong wxPython/wxWidgets to load. Then import fails and
 the thus `toolboxes.py` script fails to create the XMLs.
 >
 > r64677 removes the need to import wxPython when `toolboxes.py` is
 executed as a script. Thus the script does not need the build environment
 to be perfect. Thus it should work on Mac OS X and build the XMLs.
 >
 > This is unrelated to the original topic of this ticket. This relates to
 XML, toolboxes and menu problem mentioned in comment:10.
 >
 > > On the Mac, because of problems running wxPython for 64 bit, the
 compiling environment is forced to 32 bit for Python. That should not be a
 problem and indeed is not for all compiling except these modules, all of
 which use a new windowing class developed initially for map swipe.
 >
 > I have no idea about which class you are talking about. What the
 directories which were failing has in common is that they contain
 `g.gui.*` modules. All modules (`r.*`, `v.*`, ..., `g.gui.*`) needs to be
 executed during compilation to build manual pages. The issue is that
 `g.gui.*` required wxPython to be imported. Thus hitting the same issue
 with incomplete build environment as mentioned above. The commits r64664
 and r64674 remove the need to import wxPython packages in `g.gui.*` when
 only `grass.script.core.parser()` is called to obtain the interface
 description (execution ends with `parser()` call when the module is asked
 just for the interface using `--interface-description`). The trick in
 r64664 and r64674 is that imports are done only after `parser()` call in
 the body of `main()` function where the packages are needed (and not using
 the standard import at the begging of the file).
 >
 > > Perhaps they are trying to force the import of 64 bit wx, which is
 incorrect for current Mac compiling, and would conflict with the 32 bit
 Python environment set as default for compiling.
 >
 > They are not trying to do that, at least there is nothing in GRASS GIS
 source code which would indicate that (please check me). I cannot say what
 is in wxPython itself (do you think that there is some class?). Supposing
 that wxPython is all right, the compilation environment must be wrong.
 >
 > > That seems to be what is going on with the failure to correctly create
 the menu xml files too. The errors are the same--they cannot import wx.
 >
 > They are indeed the same and thus r64664, r64674 and r64677 are using
 the same approach of avoiding global imports of wx-related packages.
 >
 > > It acts like there is a hardwired call to Python or wxPython somewhere
 instead of calling it using the system default path.
 >
 > If there is something wrong in GRASS GIS wxGUI source code or source
 code of wxPython itself and you would find it, it would be very useful. I
 don't know where is the problem but I haven't seen anything like this in
 wxGUI source code. And wxGUI and modules are running when started from
 regular GRASS session. Therefore I think that the problem is in build
 environment, i.e. GRASS Makefiles.

 I am pretty sure that this must be either in a wxPython class created for
 mapswipe and reused for other modules OR something in the make/build
 environment used for part of the wxPython code. Or perhaps a combination
 of these. So far, I've tried to track it down, working with Anna but have
 failed so far.

 I hesitate to suggest a workaround instead of a fix. But one possibility
 that might be helpful is to automatically run the Python code to build the
 menu xml files each time GRASS is launched. This would eliminate the
 effects of this compiler problem (thought not the source). It could also
 have the benefit of providing an updated menu if there are any additions
 or subtractions to the modules in bin or scripts.

 Michael

-- 
Ticket URL: <http://trac.osgeo.org/grass/ticket/1819#comment:17>
GRASS GIS <http://grass.osgeo.org>