Bug 94780 – [EFL] Missing ENABLE(GLIB_SUPPORT) guard

• Status: RESOLVED
• Resolution: INVALID
• Component: WebKit EFL

[Gyuyoung Kim]

Some EFL port files don't use ENABLE(GLIB_SUPPORT) macro. EFL port needs to guard Glib usage in code level. However, files related to soup aren't handled by this patch because they have close glib dependency.

[Gyuyoung Kim]

Created attachment 160093 [details]
Patch

[Gyuyoung Kim]

If there was discussion related to this issue before, please let me know.

[Raphael Kubo da Costa (:rakuco)]

Do you know if disabling glib and using soup still works, as g_type_init() is not called?

[Gyuyoung Kim]

(In reply to comment #3)
> Do you know if disabling glib and using soup still works, as g_type_init() is not called?

Frankly, if we disable glib, there are too many build breaks because of soup. So, I am not sure if we should fix them at once. Even if there is no build breaks, we can't navigate any website without soup. So, GLIB_SUPPORT macro is meaningless as long as we use libsoup. However, personally, I would wrap all glib dependencies up using GLIB_SUPPORT in order to remove Glib dependencies in future. How do you think about it ?

[Raphael Kubo da Costa (:rakuco)]

(In reply to comment #4)
> Frankly, if we disable glib, there are too many build breaks because of soup. So, I am not sure if we should fix them at once. Even if there is no build breaks, we can't navigate any website without soup. So, GLIB_SUPPORT macro is meaningless as long as we use libsoup. However, personally, I would wrap all glib dependencies up using GLIB_SUPPORT in order to remove Glib dependencies in future. How do you think about it ?

That makes sense for consistency. These days, I guess it makes little sense to keep the GLIB_SUPPORT flag around, as libsoup is our only network backend and we thus always require glib to be present.

[Laszlo Gombos]

I removed the ENABLE(GLIB_SUPPORT) macro from files that are only used for EFL - http://trac.webkit.org/changeset/136884 as it does not link in its current form and is confusing.

I think we should only reintroduce this macro in EFL files if there is a desire to maintain it _and_ disabling GLIB would produce a successful build (it should at least link as a first step). As an example with the current dependencies if someone is using EFL WebKit to create an offline reader that does not need libsoup and gstreamer and that is something that the EFL port intend to support than this build flag would make sense, but in its current form it just another build flag that does not producer a successful build.

Closing the bug as invalid (for now). If the situation changes we can re-open it.

I also think we should rename the flag to USE(GLIB) - see bug 104266.