Clang warnings fix for ART backend

[trunkmaster]

These changes are:

• int formatting fixes (vast majority);
• usage of old freetype library (prior to 2.1.8 version). I've not removed ftfont-old.m though;
• removed usage of "GNU old-style field designator extension".

[trunkmaster]

Riccardo, do you have systems with old freetype library?

[rmottola]

Riccardo, do you have systems with old freetype library?

How old is "old". I Have only two systems where I still use art, one is current and up to date, the next I can check next week. < 2.1.1 ?

[trunkmaster]

On 18 Jan 2020, at 14:17, Riccardo notifications@github.com wrote:

Riccardo, do you have systems with old freetype library?

How old is "old". I Have only two systems where I still use art, one is current and up to date, the next I can check next week. < 2.1.1 ?

This line from ftfont.m :

if (FREETYPE_MAJOR==2) && ((FREETYPE_MINOR<1) || ((FREETYPE_MINOR==1) && (FREETYPE_PATCH<8)))

specifies version < 2.1 or < 2.1.8. Could you check if that system can work without art/ftfont-old.m file?

[trunkmaster]

@rmottola, any news?

[rmottola]

@trunkmaster I have some news. First, the old machine (it is the small MIPS minbook which Fred will remember and which for kernel reasons I cannot update to newer versions of Debian) has FreeType 2.2, so in "theory" there should be no issue! I rebuilt all gnustep "from scratch" natively, to test your patch. It builds, but fails. I noticed that libart is not netected, so I got a fallback on xlib. I need to investigate that. Xlib then fails with a crash (the reason I was using libart on this machine in the first place, there are issues with the system fonts. It used not to crash, but to draw no strings on the screen, I think this a "regression", but a different issue.

I will try to report back "why" libart is not being found, I will write to the mailing list, please bear some patience.

[trunkmaster]

@rmottola, no problem. Waiting for report on libart issue.