[Webkit-unassigned] [Bug 218201] New: [WPE][GTK] Ensure either ENABLE_JIT or ENABLE_C_LOOP is enabled(?)

[bugzilla-daemon at webkit.org]

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

            Bug ID: 218201
           Summary: [WPE][GTK] Ensure either ENABLE_JIT or ENABLE_C_LOOP
                    is enabled(?)
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: WebKitGTK
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: mcatanzaro at gnome.org
                CC: bugs-noreply at webkitgtk.org, guijemont at igalia.com,
                    xan.lopez at gmail.com

In bug #217989, I mentioned that Red Hat and SUSE accidentally shipped WebKit builds with both JIT and cloop disabled. i.e. JSC was using assembler-based llint interpreter rather than cloop. Carlos Lopez requested we add a check to prevent this from happening:

(In reply to Carlos Alberto Lopez Perez from comment #12)
> I think we should add a check in cmake to ensure that one (and only one) of
> JIT or C_LOOP is enabled, so that we don't allow building with both options
> disabled (or with both enabled)

That makes sense to me. I would do this only in OptionsGTK.cmake and OptionsWPE.cmake, though, because I know Apple does not want that restriction for its ports, and we don't want to make transitioning to CMake any harder. But because ENABLE_C_LOOP and ENABLE_JIT are both PRIVATE settings, and WebKitFeatures.cmake normally ensures exactly one or the other is always enabled, checking to ensure it hasn't somehow happened probably makes sense for us. We could change that and remove this restriction if Igalia JSC developers ever want to do so, but that's the status quo currently, and enforcing it would avoid mistakes where we accidentally ship with a different JSC than everybody else, with our own special bugs.

Counterargument: we don't support changing the values of PRIVATE settings, and this error will never happen if you don't do that. If bug #217989 is fixed, then distros will no longer have to mess with PRIVATE settings, so there is less value in adding that check. Alternative: maybe you really do know what you're doing and intentionally want to experiment with both JIT and cloop disabled? If so, then removing this check manually will be annoying.

Anyway, I'll submit a patch, and we can see what people think.

-- 
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/20201026/64380a17/attachment.htm>