On Tue, May 25 2021 at 06:22:41 AM -0500, Michael Catanzaro via
webkit-dev wrote:
I'm hoping there are not very many warnings, since I've been cleaning
warnings I see for several years now. There will probably be a few,
though, which could be caused by (a) EWS using non-default build
options
On Mon, May 24 2021 at 07:36:03 PM -0700, Darin Adler via webkit-dev
wrote:
I do not know why we do not already use -Werror on GTK and WPE and I
support using it there after fixing all the warnings.
I'd be willing to enable it at the CMake level if it was conditional on
On Mon, May 24 2021 at 06:32:03 PM -0700, Darin Adler via webkit-dev
wrote:
But we can’t just turn on -Werror until after we fix all the
warnings! Who will do that project.
I'm hoping there are not very many warnings, since I've been cleaning
warnings I see for several years now. There will
Sorry, I should clarify.
Apple’s ports of WebKit already use -Werror and always have, everywhere, not
just on EWS. Since day one.
I do not know why we do not already use -Werror on GTK and WPE and I support
using it there after fixing all the warnings.
— Darin
I’m a big fan of -Werror. Back when WebKit started, it was controversial to use
it at Apple.
But we can’t just turn on -Werror until after we fix all the warnings! Who will
do that project.
— Darin
___
webkit-dev mailing list
On Mon, May 24 2021 at 05:42:37 PM -0500, Michael Catanzaro
wrote:
But really, rather than cherry-picking particular warning flags,
using -Werror seems simplest to me. Problematic warnings should be
disabled or suppressed.
We might want to globally suppress -Warray-bounds and -Wnonnull when
Hi,
I'd like to suggest turning on -Werror on at least the GTK and WPE EWS,
to reduce the amount of time I spend cleaning up newly-introduced build
warnings. ;)
If we're worried about too many spurious build failures, let's at least
build with a few flags to prevent the most common GCC
7 matches
Mail list logo