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