[GRASS-dev] grass7 on mac OSX

[Glynn Clements]

William Kyngesburye wrote:

> I had to restore the -U __GNUC__.  Without it, I get a lot of syntax
> errors in GRASS headers.

Right; that will be due to this:

	#if !defined __GNUC__ || __GNUC__ < 2
	#undef __attribute__
	#define __attribute__(x)
	#endif

If __GNUC__ is defined, the __attribute__ declarations will be
retained, which ctypesgen won't like. This will cause it to omit
wrappers for any function with an __attribute__ declaration; most of
these are __attribute__((format,...)), i.e. G_message() etc. 
G_fatal_error() also has __attribute__((noreturn)).

> With, though I get that unknown architecture
> error in nviz.py.  The ctypesgen authors seem to be aware of and patch
> OSX issues, but maybe they never tried it with system framework headers.

But does this prevent the generation of the wrapper?

> Besides that, both with and without __GNUC__, there is the escape error
> in nviz.py:

> ValueError: invalid \x escape in ".HFS+ Private Directory Data\xd"

Right; my proposed fix (r42484) should handle that.

> I found that string in /usr/include/hfs/hfs_format.h:
> 
> #define HFSPLUS_DIR_METADATA_FOLDER ".HFS+ Private Directory Data\xd"
> 
> Probably included somewhere in the trail from ApplicationServices.h.
> Looks like a single-digit escape, so I tried your re.sub above.  It then
> makes it thru that ValueError, but then there are tons of syntax errors
> in system headers.  One example:
> 
> Error: /System/Library/Frameworks/CoreFoundation.framework/Headers/CFString.h:820: Syntax error at '{'
> Error: /System/Library/Frameworks/CoreFoundation.framework/Headers/CFString.h:821: Syntax error at '>='
> 
> This is the code there:
> 
> CF_INLINE Boolean CFStringIsSurrogateHighCharacter(UniChar character) {
>     return ((character >= 0xD800UL) && (character <= 0xDBFFUL) ? true : false);
> }
> 
> There are more similar CF_INLINE definitions earlier, but they are
> inside a #ifdef CF_INLINE.

But do these prevent the wrapper from being generated, or result in it
missing necessary definitions?

ctypesgen ignores errors from the preprocessor (it doesn't capture
stderr and doesn't care about the exit code). Errors only matter
insofar as they cause significant declarations to be omitted or
malformed.

The ValueError is different as that's an exception being raised within
ctypesgen itself; r42484 should deal with that.

-- 
Glynn Clements <glynn at gclements.plus.com>