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

[bugzilla-daemon at webkit.org]

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

Michael Catanzaro <mcatanzaro at igalia.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #272458|review?                     |review-
              Flags|                            |

--- Comment #16 from Michael Catanzaro <mcatanzaro at igalia.com> ---
Comment on attachment 272458
  --> https://bugs.webkit.org/attachment.cgi?id=272458
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.

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.

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.

-- 
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/a7c879bc/attachment-0001.html>