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 <gl...@gclements.plus.com> _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev