[GRASS-dev] grass7 on mac OSX

[Barton Michael]

Once you or others think there is a potential fix for GRASS for OSX, I'm happy to give it a try.

MIchael
____________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity 
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University

voice: 	480-965-6262 (SHESC), 480-727-9746 (CSDC)
fax:          480-965-7671 (SHESC),  480-727-0709 (CSDC)
www: www.public.asu.edu/~cmbarton, http://csdc.asu.edu










On Jun 4, 2010, at 7:01 AM, Glynn Clements wrote:

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