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

[bugzilla-daemon at webkit.org]

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

--- Comment #20 from Carlos Alberto Lopez Perez <clopez at igalia.com> ---
(In reply to Michael Catanzaro from comment #15)
> So, back to your question:
> 
> > Why we don't convert all private options to unconditional definitions that
> > can't be changed of value?
> 
> You're right: you have a very strong argument for doing so. We could, for
> example, change this:
> 
>          option(${_name} "${_WEBKIT_AVAILABLE_OPTIONS_DESCRIPTION_${_name}}"
>  ${_WEBKIT_AVAILABLE_OPTIONS_INITIAL_VALUE_${_name}})
>          if (NOT ${_WEBKIT_AVAILABLE_OPTIONS_IS_PUBLIC_${_name}})
>              mark_as_advanced(FORCE ${_name})
>          endif ()
> 
> To this:
> 
>          if (${_WEBKIT_AVAILABLE_OPTIONS_IS_PUBLIC_${_name}})
>              option(${_name}
> "${_WEBKIT_AVAILABLE_OPTIONS_DESCRIPTION_${_name}}"
>  ${_WEBKIT_AVAILABLE_OPTIONS_INITIAL_VALUE_${_name}})
>          endif ()
> 
> And then that would resolve this little debate. The disadvantage being that
> you would now have to modify the CMake build system if experimenting with
> the PRIVATE options as a developer.
> 
> I have no strong preference as to whether we should change this or not. If
> you want to do it (and it doesn't break other ports' bots), I'll give r=me.
> 

Definitively I think we should not allow to modify build options via a simple cmake switch argument (even if that is somehow hidden) and at the same time not accept patches to fix the breakage when that is modified.

So, I think we should make the current private options not options anymore, but unconditional values. Or at least only allow this values to be modified when DEVELOPER_MODE is enabled. 

At the same time that means we will have to make options that are current private public (like woff2).

And that will be better (IMHO) than the current status quo where there are lot of hidden options for which we don't accept patches to fix the breakage (which is kind of an unwritten rule), and where several downstream are toying with this config options.

-- 
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/20180507/20636fd1/attachment.html>