I can set this up to exclude deprecation warnings. When I turn on warnings-as-errors and exclude deprecations there are only a handful of changes needed in glass. I think they could be handled in a single pull request. I’ll need an issue number; will I be able to enter a bug for this through the public portal?
I don’t want to hide deprecation warnings entirely since they do sometimes flag issues worth investigating (one is now on my to-do list). It’s still a lot of warnings so it’s probably worth coming up with a strategy for reducing them over time. > On Nov 29, 2021, at 10:10 AM, Kevin Rushforth <kevin.rushfo...@oracle.com> > wrote: > > 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 <mar...@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. >>> >>> >>> >>> >
