[Webkit-unassigned] [Bug 235444] [GTK][STABLE] More missing headers for non-unified 2.34.3 build

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri Jan 21 13:04:13 PST 2022


Michael Catanzaro <mcatanzaro at gnome.org> changed:

           What    |Removed                     |Added
                 CC|                            |mcatanzaro at gnome.org

--- Comment #1 from Michael Catanzaro <mcatanzaro at gnome.org> ---
Comment on attachment 449665
  --> https://bugs.webkit.org/attachment.cgi?id=449665
more missing headers and buggy ENABLE preprocessing

View in context: https://bugs.webkit.org/attachment.cgi?id=449665&action=review

Hi, to land in WebKit you'd need (a) ChangeLog entries generated with the prepareChangeLog script, and (b) r? Bugzilla flag set.

Fixes should land in trunk first, then a second patch fixing the issues in the stable branch can be accepted second. If we fix the issues in stable first without fixing trunk, that just sets us up to have the same problems again next release.

#include fixes and #if fixes are best split into two separate patches, not all in one patch, to match the title of the bug (which is your commit message title).

Lastly, while #if fixes in cross-platform code are always welcome, in the platform-specific code we instead prefer to minimize the number of preprocessor guards that we use. Changing the value of private build options is not supported at all and that's not expected to build successfully. There's no reason to ever build GTK port with fullscreen API or resource load statistics disabled, for example, because they have no build dependencies. I guess you might save a few bytes on disk, but that's not worth the cost of maintaining the guards in our code. Building without ENABLE_USER_MESSAGE_HANDLERS will disable some pretty core functionality. These flags are private because it doesn't make sense to use them. If you really want them for some reason, please propose a patch to expose them as public, including justification for why it makes sense to build without.

> b/Tools/MiniBrowser/gtk/BrowserTab.c:345
> +    }

Careful here too.

> b/Tools/MiniBrowser/gtk/BrowserTab.c:360
> +    }
> +#endif

Careful with indentation

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/20220121/d9359f23/attachment-0001.htm>

More information about the webkit-unassigned mailing list