#3610: Python ctypes MacOS: add more “-D” options to CTYPESFLAGS to make it work
(almost)
-------------------------+-------------------------
Reporter: vince | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone:
Component: Default | Version: unspecified
Keywords: | CPU: Unspecified
Platform: Unspecified |
-------------------------+-------------------------
**ctypesgen** miserably fails on MacOS.
I found the situation could be much improved if you add this defines:
''\"-Drestrict=\" \"-D_ _attribute_
_(x)=\" \"-D_Nullable=\" \"-D_Nonnull=\"'' to CTYPESFLAGS
The situation is not ideal, however. ''cpl_port.h'' as installed by GDAL
needs a small patch too, because <x86intrin.h> won’t parse. I’m planning
to ask the GDAL developers if this line is mandatory with CLANG. In the
meanwhile the Makefile should make a private copy of this file, modify it
and use it.
Also, a system file needs a patch, though that might not be necessary
(#warning condition treated as an error).
Finally, NVIZ is beyond hope. The AGL framework is deprecated, uses Carbon
as a framework, which is still more deprecated, and that makes the parsing
almost impossible to set straight. Does grass rely on NVIZ, or it is
possible to add an option to disable 3D viz? That'd be nice.
#3610: Python ctypes MacOS: add more “-D” options to CTYPESFLAGS to make it work
(almost)
--------------------------+-------------------------
Reporter: vince | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone:
Component: Default | Version: unspecified
Resolution: | Keywords:
CPU: Unspecified | Platform: Unspecified
--------------------------+-------------------------
Comment (by cmbarton):
I don't understand the NVIZ comment. It is currently working fine with the
newest High Sierra OS X, compiled 64 bit, with wxPython 4.0. We may run
into problems down the line of course, but it is not a problem now. Also
Huidae Cho just managed to fix m.nviz.image for the Mac, updating its use
of OpenGL.
#3610: Python ctypes MacOS: add more “-D” options to CTYPESFLAGS to make it work
(almost)
--------------------------+-------------------------
Reporter: vince | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone:
Component: Default | Version: unspecified
Resolution: | Keywords:
CPU: Unspecified | Platform: Unspecified
--------------------------+-------------------------
Comment (by hcho):
By default (without {{{#define OPENGL_AGL}}} in config.h), trunk uses the
Core OpenGL (CGL), which is the lowest-level OpenGL API for the Mac. The
AGL code is still there just in case, but not used anymore since r73006.
#3610: Python ctypes MacOS: add more “-D” options to CTYPESFLAGS to make it work
(almost)
--------------------------+-------------------------
Reporter: vince | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone:
Component: Default | Version: unspecified
Resolution: | Keywords:
CPU: Unspecified | Platform: Unspecified
--------------------------+-------------------------
Comment (by vince):
I don’t imply it’s not working. It’s the CTYPEGEN parsing which generates
a lot of errors. Maybe I’m misconfiguring GRASS, so I’ll check out once
more and hopefully come back with updated info.
#3610: Python ctypes MacOS: add more “-D” options to CTYPESFLAGS to make it work
(almost)
--------------------------+-------------------------
Reporter: vince | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone:
Component: Default | Version: unspecified
Resolution: | Keywords:
CPU: Unspecified | Platform: Unspecified
--------------------------+-------------------------
Comment (by vince):
I suspect most of your errors stem from this line (around 690) in
cpp_port.h, which is part of GDAL:
{{{ #include <x86intrin.h>
}}}
If you comment this line, do you still have those errors? If not, then
it'd be worth to consider what I suggested: use a slightly altered version
of this include file, copying it locally and commenting out that line
which does not contribute to anything in ctype
#3610: Python ctypes MacOS: add more “-D” options to CTYPESFLAGS to make it work
(almost)
--------------------------+-------------------------
Reporter: vince | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone:
Component: Default | Version: unspecified
Resolution: | Keywords:
CPU: Unspecified | Platform: Unspecified
--------------------------+-------------------------
Comment (by hcho):
Replying to [comment:4 vince]:
> Ah, this hasn't made it to a release yet.
> Is the new OpenGL based code activated by using --with-opengl=osx in
configure?
> Thanks
>
> PS: I don’t want to rain on the parade in any way, but OpenGL will be
officially deprecated in OS X Mojave 10.14 to be released during fall…
Yep! Like always, they've created their own stuff (innovation?), Metal
API. Hopefully, there will be an Open Source wrapper library that provides
a cross-platform abstract layer for both OpenGL and Metal.
#3610: Python ctypes MacOS: add more “-D” options to CTYPESFLAGS to make it work
(almost)
--------------------------+-------------------------
Reporter: vince | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone:
Component: Default | Version: unspecified
Resolution: | Keywords:
CPU: Unspecified | Platform: Unspecified
--------------------------+-------------------------
Comment (by vince):
To be honest, OpenGL is a technology born in the 80s, and I think it has
really overstayed its welcome.
Apple could have moved to Vulkan. They chose to go their own path. You’re
right, this wasn't really smart. I suspect the Khronos group is fraught
with tension between the various manufacturers, and Apple might have bowed
out after being met with ferocious opposition (especially from Nvidia).
I’m also very sorry they decided to deprecate OpenCL.
#3610: Python ctypes MacOS: add more “-D” options to CTYPESFLAGS to make it work
(almost)
--------------------------+-------------------------
Reporter: vince | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone:
Component: Default | Version: unspecified
Resolution: | Keywords:
CPU: Unspecified | Platform: Unspecified
--------------------------+-------------------------
Comment (by neteler):
Replying to [comment:7 vince]:
> I suspect most of your errors stem from this line (around 690) in
cpp_port.h, which is part of GDAL:
Guess you mean
/usr/include/gdal/cpl_port.h
>
> {{{
> #include <x86intrin.h>
> }}}
>
> If you comment this line, do you still have those errors? If not, then
it'd be worth to consider what I suggested: use a slightly altered version
of this include file, copying it locally and commenting out that line
which does not contribute to anything in ctype
Confirmed! All ctype parse issues are gone then on my Fedora 28 box by
commenting that line in /usr/include/gdal/cpl_port.h
