[GRASS-dev] grass7 on mac OSX

[Glynn Clements]

William Kyngesburye 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.

It does (via "gcc -E").

> 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).

The version in GRASS is r72 (the version I have installed via Gentoo). 
Martin was having problems with the latest trunk version.

> 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.

An error building lib/python/ctypes is currently non-fatal, as it
isn't used for anything except wxNVIZ.

> Removing the -U __GNUC__ causes even more errors.

So do we remove it or keep it? I can only guess that the #error's were
being triggerd by __GNUC__ being undefined. Is there some other
setting which will work?

>  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.

I'll add that.

> 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

Okay; I've added these.

> - 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.

The question is whether the errors are recoverable. I don't think
we'll know that until we deal with the ValueError issue.

> 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

Can you provide more details? It should be possible to modify
ctypesgen to recover from this.

> (make error, yet it doesn't get caught by the grass error
> log).

An error in the ctypes subdirectory should now be logged.

-- 
Glynn Clements <glynn at gclements.plus.com>