Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

make: use compiler switches to control warnings/errors behavior #263

Merged
merged 0 commits into from
Jan 20, 2025

Conversation

jstine35
Copy link
Collaborator

@jstine35 jstine35 commented Jan 20, 2025

  • Improves printf verification for lutro assertions when using clang compiler
  • Consolidates warning behavior into makefile and vcxproj file
  • Reduced impact to disable only one specific warning which is deemed "generally harmless" : use of the gnu varadic macro extension. All other warnings are enabled.

Note that printf formatting verification is not supported on the gnuc compiler.

On Validation in MSC

I discovered today that MSVC 2022 provides a new command line feature /MX: which works as a compact and streamlined solution to promoting warnings to errors from the vcxproj/props sheets. Prior to VS2022 this could only be accomplished by using #pragma directives, which were not available at the build-system level.

https://learn.microsoft.com/en-us/cpp/build/reference/wx-treat-linker-warnings-as-errors?view=msvc-170

However the printf validation of Microsoft's C compiler are ineffective: it conflicts with the printf redirection macro which is used to surface console logs to the VS output window (it was intended for C++ and does not allow printf validation in C99), and because of this, and given that clang-cl is preferred over Microsoft C, I favored the minimalist approach and implemented only clang-cl formatting options (which as an added benefit, are self-documenting).

Aside: The redirection to the VS Output window is itself a low-value behavior nowdays, thanks to drastic improvements and upgrades made to Windows Terminal applications since 2021 or so. Probably also worth scrapping.

@jstine35 jstine35 requested a review from kivutar January 20, 2025 01:55
@jstine35 jstine35 force-pushed the remove_forceinclude branch from 6195ac7 to edc3b7e Compare January 20, 2025 02:08
@jstine35 jstine35 force-pushed the remove_forceinclude branch from edc3b7e to b347424 Compare January 20, 2025 15:42
@jstine35 jstine35 merged this pull request into libretro:master Jan 20, 2025
10 checks passed
@jstine35 jstine35 deleted the remove_forceinclude branch January 21, 2025 15:25
@jstine35 jstine35 restored the remove_forceinclude branch January 22, 2025 06:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants