[Webkit-unassigned] [Bug 154512] Added new port JSCOnly.

[bugzilla-daemon at webkit.org]

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

--- Comment #17 from Konstantin Tokarev <annulen at yandex.ru> ---
(In reply to comment #16)
> Comment on attachment 272458 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=272458&action=review
> 
> > 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.

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

> 
> 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.

I'll add option to choose event loop type by name, with GLib being default for now (later default should depend on OS).

> 
> 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.

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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20160228/2cd16e1b/attachment-0001.html>