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
_______________________________________________
grass-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-dev
