Python ctypes MacOS: add more “-D” options to CTYPESFLAGS to make it work (almost)

[vince]

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.

Thanks.

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

[hcho]

By default (without #define OPENGL_AGL 1 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.

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

[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 release during fall… :( :(

[neteler]

F28 build log of ctypes with parse errors

[neteler]

Also on Fedora 28 parse errors occur: attached the F28 build log excerpt of ctypes subdir

[hellik]

Replying to neteler:

Also on Fedora 28 parse errors occur: attached the F28 build log excerpt of ctypes subdir

see also, maybe related

#3368 #3464

[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

[hcho]

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

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

[cmbarton]

So what's a potential cross-platform 3D rendering engine to replace OpenGL in future NVIZ?

[vince]

There is, I think, an open-source library that abstracts the Metal API into a Vulkan compatible API. That might work.

[neteler]

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