[GRASS-dev] grass7 on mac OSX

[William Kyngesburye]

trying to catch up on all this...

On Jun 3, 2010, at 12:05 AM, Glynn Clements wrote:

> 
> Massimo Di Stefano wrote:
> 
>> i applied the patch and tried to rebuild (after make distclean)
>>  File "/Users/Shared/source/grass_trunk/lib/python/ctypes/ctypesgencore/parser/pplexer.py", line 60, in __new__
>>    value = value[1:-1].decode('string_escape')
>> ValueError: invalid \x escape
> 
> This looks like an issue with Apple's "C" headers being incompatible
> with anything other than Apple's version of gcc.
> 
> I think that it's going to need someone with a Mac to investigate the
> issues and make the necessary changes to ctypesgen to either support
> Apple's "enhanced" C dialect, or to provide the necessary switches to
> disable the enhancements (if such switches exist).
> 
Apple's GCC is GCC.  The preprocessor is custom.  When I looked into ctypesgen, it says it uses the preprocessor.

Did you take a trunk snapshot of ctypesgen?  When?  I see a lot of differences between the current ctypesgen trunk and the copy in GRASS trunk.  The last batch of changes was in March.  And there is a OS X 10.6-specific fix in there (adding -U __BLOCKS__ to the parse command).

What I'm seeing so far is that there are errors in lib/python/ctypes that are not showing up in the GRASS error log, so Michael and Massimo might have missed them.

Removing the -U __GNUC__ causes even more errors.  Adding the -U __BLOCKS__ bit that's in trunk removes a couple errors.  Using ctypesgen trunk does no more than adding the -U __BLOCKS__ bit.

Errors I'm getting (after adding the -U __BLOCKS__ change):

- gprojects.h (from proj.py) can't find proj_api.h or ogr_srs_api.h - their -I's are not in the ctypesgen preprocessor command

- same for ogr and geos headers in vector.py and vedit.py

- nviz.py: /usr/include/TargetConditionals.h:284:10: error: #error TargetConditionals.h: unknown compiler
  (probably included from needing AGL and Application Services headers from the system)
  this appears to be caused by undefining __GNUC__, but leaving __GNUC__ defined causes lots of syntax errors in system headers, which spill into grass headers.  I don't know how this can be fixed.

proj.py, vector.py and vedit.py still get created, though I don't know if they work.  nviz.py has a ValueError: invalid \x escape, and doesn't get created (make error, yet it doesn't get caught by the grass error log).


For wxpython, as Michael and others have reported, wxpython does not get compiled.  The error has to do with it using the system python executable, which runs 64bit, but wxpython is not 64bit.  This has come up before and there was no solution implemented.  At runtime, OSX GRASS has a python wrapper that will run python in 32bit mode if needed by wxpython, but this is not available at compile time.

The workaround is to copy this wrapper to some location and add that location to your PATH before compiling.

I think the reason it used to work when compiling inside the wxpython folder is that the top level compile would compile the OSX app, which copied the python wrapper to the dist/bin folder.  Then running make in wxpython would run the python wrapper for compiling vdigit/nviz.  When I changed the OSX app makefiles to simplify them (r42158), I made this step an install step.

What do you think of this: I restore the python wrapper as a compile step, to copy it to dist/bin, then reorder the Mac compilation to be before lib (compilation in the macosx does not depend on any GRASS compilation)?  This would fix the wxpython 32/64bit compilation problem on OSX.

Or I could move the python wrapper copy-to-bin step to lib/init?

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

"I ache, therefore I am.  Or in my case - I am, therefore I ache."

- Marvin