[GRASS-dev] Re: [GRASS GIS] #308: Compiler error while building python swig

[GRASS GIS]

#308: Compiler error while building python swig
----------------------------------+-----------------------------------------
  Reporter:  cgsbob               |       Owner:  grass-dev at lists.osgeo.org
      Type:  defect               |      Status:  new                      
  Priority:  major                |   Milestone:  6.4.0                    
 Component:  SWIG (all bindings)  |     Version:  svn-develbranch6         
Resolution:                       |    Keywords:  python swig              
  Platform:  Unspecified          |         Cpu:  Unspecified              
----------------------------------+-----------------------------------------
Comment (by glynn):

 Replying to [comment:10 hamish]:

 > Perhaps leaving out G_fatal_error() is good due to the exit(1).

 SWIG needn't just be for wxGUI. It should be possible to write modules in
 Python (full raster processing in Python is likely to be slow, but code
 which only deals with support files isn't a problem), and those modules
 may need to call G_fatal_error().

 > My guess is that access to the core GIS engine processing functions is
 the thing real value to SWIGers. Python probably has its own (possibly
 nicer) versions of any G_string_manipulate() function that libgis
 provides.

 A Python function can only be "equivalent" to a libgis function if the
 libgis function has clearly defined behaviour which won't change in future
 versions. If there's any chance that the behaviour might change, Python
 code should normally call the libgis function to ensure consistent
 behaviour.

 [Here, I'm talking about Python code which already needs to call GRASS
 functions for other reasons. An otherwise "pure" Python script shouldn't
 import GRASS' SWIG bindings for something so minor as G_message().]

 > AFAIU #includes are ignored/not followed, so I'll filter those out to
 avoid confusion, while leaving other preprocessor #ifdefs and #defines in
 place.

 If they're ignored, there's no specific need to filter them out.

 > > But then there's the more fundamental problem that the other
 > > interfaces/*.i files are duplicating information from the headers,
 > > and are somewhat out of date. And it's safe to say that anything
 > > which attempts to duplicate information from the headers will be
 > > continually out of date. The SWIG stuff is going to have to use
 > > the actual headers directly.
 >
 > Right, AFAIK that's a known issue and not done currently simply because
 it is still waiting on the TODO list and none of the devels are actively
 working this part of the code.

 What's to do? Just remove the .i files and %include the .h files directly.

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