Cleaning up warnings in the Mac glass code

[Kevin Rushforth]

I agree that this would be a good thing to aim for as long as we exclude 
deprecation warnings (given Apple's penchant for deprecating large API 
surfaces such as OpenGL or the older accessibility APIs we really can't 
have the use of deprecated APIs be an error).

-- Kevin


On 11/24/2021 7:44 PM, Michael Strauß wrote:
> That's a good idea. In general, warnings should always be treated as errors.
>
>
> On Thu, Nov 25, 2021 at 2:01 AM Martin Fox <martin at martinfox.com> wrote:
>> The Mac glass code generates a lot of compiler warnings. I tried cleaning this up and discovered that two of the warnings are brand new, courtesy of me. One of the headers in PR #651 has a typo that I didn’t catch and neither did the two reviewers. The compiler generated two warnings but they were lost in the sea.
>>
>> I turned on warnings-as-errors for the Mac glass code and waded through the results. There are a couple of minor coding errors in addition to mine which should be cleaned up (like passing NO to a function that requires a non-null pointer). There’s also a few deprecated calls across a small handful of files which have easy replacements and are probably worth fixing.
>>
>> Unfortunately Apple re-named a bunch of constants in 10.12 and deprecated the older forms (I think this was to rationalize the naming with Swift). These form the bulk of the warnings and affect multiple files. Not a fan of that sort of code churn but the alternative is to live with a slew of warnings forever. Apple is not going to un-deprecate those constants.
>>
>> You can see the changes I made in my github repository (beldenfox/jfx) in the branch ‘macwarnings’. There’s multiple commits, the first and biggest catching most of the easy stuff like constant renaming.
>>
>> In the short term it might be worth disabling deprecation warnings and turning on warnings-as-errors. Then at least outright coding errors (like mine!) have a chance of being caught.
>>
>>
>>
>>