<html>
<head>
<base href="https://bugs.webkit.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - Added new port JSCOnly."
href="https://bugs.webkit.org/show_bug.cgi?id=154512#c17">Comment # 17</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - Added new port JSCOnly."
href="https://bugs.webkit.org/show_bug.cgi?id=154512">bug 154512</a>
from <span class="vcard"><a class="email" href="mailto:annulen@yandex.ru" title="Konstantin Tokarev <annulen@yandex.ru>"> <span class="fn">Konstantin Tokarev</span></a>
</span></b>
<pre>(In reply to <a href="show_bug.cgi?id=154512#c16">comment #16</a>)
<span class="quote">> Comment on <span class=""><a href="attachment.cgi?id=272458&action=diff" name="attach_272458" title="Patch">attachment 272458</a> <a href="attachment.cgi?id=272458&action=edit" title="Patch">[details]</a></span>
> Patch
>
> View in context:
> <a href="https://bugs.webkit.org/attachment.cgi?id=272458&action=review">https://bugs.webkit.org/attachment.cgi?id=272458&action=review</a>
>
> > Source/WTF/wtf/WorkQueue.h:43
> > +#elif USE(GLIB)
>
> Honestly, I think the way you have it here is best: use DispatchQueueEfl for
> EFL, otherwise use the GLib stuff. This isn't the only place we have such
> conditionals. I think it's nicer this way than introducing new
> USE(EVENTLOOP_GLIB) USE(EVENTLOOP_EFL) flags.</span >
My concerns rehashed:
1. It is possible to make JSCOnly building with EFL loop, but it doesn't seem to be a good idea to define PLATFORM(EFL) in this case. Same goes for DARWIN and WINDOWS cases.
2. USE(GLIB) does not mean "Use GLib enent loop" in generic case
<span class="quote">>
> Anyway, changing from PLATFORM(GTK) to USE(GLIB) is definitely correct.
>
> > Source/cmake/OptionsJSCOnly.cmake:28
> > + SET_AND_EXPOSE_TO_BUILD(USE_GLIB 1)
>
> But I'm uncomfortable with autodetecting GLib support and silently disabling
> it if not present. This means some users will have a broken JSC due to the
> missing RunLoop/WorkQueue implementations, and others will not, even while
> building in exactly the same way, based on the presence of development files
> for some seemingly-random library.
>
> One solution is to make this a public option, on by default, with a
> descriptive error message (without GLib, this and this will break) so users
> have to explicitly pass -DUSE_GLIB=OFF to CMake to build without it. I would
> r+ such a patch.</span >
I'll add option to choose event loop type by name, with GLib being default for now (later default should depend on OS).
<span class="quote">>
> But even so, it seems like a broken vs. not broken option to me. Perhaps
> best to just require GLib for now, and work on a new WorkQueue
> implementation to remove the dependency later. GLib has very few
> dependencies and it's available everywhere; it would be nice to have no
> dependency on GLib, but I don't think it's so horrible.</span >
I don't agree with "broken vs. not broken" part. "None" is not broken, it is just not feature complete, e.g. all tests from run-layout-jsc pass.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>