[Webkit-unassigned] [Bug 185253] [WPE] Fix build for ENABLE_TOUCH_EVENTS=OFF

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri May 4 03:09:14 PDT 2018


--- Comment #14 from Pablo Saavedra <psaavedra at igalia.com> ---
(In reply to Michael Catanzaro from comment #12)
> (In reply to Michael Catanzaro from comment #11)
> > (That said, I don't have a strong opinion about this; if Zan wants
> > ENABLE_TOUCH_EVENTS to be PUBLIC, then that's fine with me.)
> Basically the tradeoffs I see to exposing it are:
> * Benefits: none(?)
> * Cost: one more configuration that can (and, obviously, will) often fail to
> build

What you usually refers like PUBLIC/PRIVATE is translated in cmake advance variables:

            mark_as_advanced(FORCE ${_name})
        endif ()

(L257 in cmake/WebKitFeatures.cmake)

This doesn't means you can't set this value in advanced mode, right?

mark_as_advanced([CLEAR|FORCE] VAR [VAR2 ...])

 Mark the named cached variables as advanced. An advanced variable will not be 
 displayed in any of the cmake GUIs unless the show advanced option is on. If 
 CLEAR is the first argument advanced variables are changed back to unadvanced. 
 If FORCE is the first argument, then the variable is made advanced. If neither 
 FORCE nor CLEAR is specified, new values will be marked as advanced, but if 
 the variable already has an advanced/non-advanced state, it will not be 

I'd suggest keep the option as PRIVATE (as in the current version of the patch) and allowing the advance users activate/deactivate this flag. It makes more sense to me.

In opposite, if you don't prefer don't support touch events set to OFF, then I'd prefer inhibit set this as true with something like:


Anyway, I see interested enough keep the choice to swap off/on the touch events feature.

ref: https://cmake.org/cmake/help/v3.0/command/mark_as_advanced.html

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/20180504/f202aec2/attachment.html>

More information about the webkit-unassigned mailing list