[Webkit-unassigned] [Bug 246520] New: [libpas] Built with -Werror

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=246520

            Bug ID: 246520
           Summary: [libpas] Built with -Werror
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: bmalloc
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: mcatanzaro at gnome.org
                CC: ggaren at apple.com

Currently libpas is built with -Werror. This is not OK because it's used unconditionally, so it's enabled in release tarballs. This has been considered bad practice for a very long time because it's likely to cause spurious build failures for anyone not using the exact same compiler version tested by the developers.

It's OK to use -Werror, but only an opt-in basis. We need to make sure it gets enabled only for developers and never for normal builds. We already have a DEVELOPER_MODE_FATAL_WARNINGS flag for this purpose, but it only works for stuff that uses WEBKIT_FRAMEWORK, WEBKIT_EXECUTABLE, or WEBKIT_WRAP_EXECUTABLE, and it looks like libpas does not use any of that. I guess libpas is avoiding use of WebKit macros in case we want to split it out from WebKit's source tree in the future, so that it can be used by other projects? If so, I suppose we cannot look at DEVELOPER_MODE_FATAL_WARNINGS. Adding a libpas-specific flag to opt-in to fatal warnings separate from DEVELOPER_MODE_FATAL_WARNINGS doesn't sound very appealing to me, but it's an option. For now, I will just remove -Werror to get us into a reasonable state. libpas maintainers can decide their preference for else to enable fatal warnings. Just setting CXXFLAGS=-Werror seems entirely reasonable to me, though. ;)

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20221014/59dcb680/attachment.htm>