[Webkit-unassigned] [Bug 142865] [GTK] Add a configure option to build without Redirected XComposite Window

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri Mar 20 01:11:57 PDT 2015


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

--- Comment #12 from Gwang Yoon Hwang <yoon at igalia.com> ---
(In reply to comment #10)
> (In reply to comment #4)
> > (In reply to comment #3)
> > > (In reply to comment #2)
> > > > This feature looks okay for me.
> > > > How about to use "USE" instead of "ENABLE"?
> > > 
> > > hmm, I really don't mind to use USE, is there any policy or convention?
> > 
> > Because I'm outside right now, i cannot find a reference. 
> > as far as I understand, ENABLE used for feature, but this patch provides
> > Another way for a same purpose. So i thought USE is more appropriate.
> 
> In Platform.h
> 
> /* USE() - use a particular third-party library or optional OS service */
> /* ENABLE() - turn on a specific feature of WebKit */
> 
> I would probably use USE if we could decide whether to use it or not
> depending only on the dependencies or other command line options (for
> example disable it for wayland or when using the threaded compositor), but
> since it's an option exposed to the user as a command line option, I
> followed what other options do. CMake configure options are already
> confusing enough, having -DNABLE_FOO and -DUSE_FOO options could make it
> even more confusing. But still, if you guys think USE fit better for this
> case I don't mind to change it.

Thanks for clarify the convention. :)
Still I'm prefer to use "USE" because XCompositeWindow relies on the XComposite and XDamage which is a optional OS service.


To match the convention, it is also good to use USE(REDIRECT_COMPOSITING) and enable it as a default, but I think just replacing it to USE is also okay.

-- 
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/20150320/955c95ef/attachment-0002.html>


More information about the webkit-unassigned mailing list