Bug 175040 – WebKitEnumTypes.h:27:0: error: unterminated #ifndef WEBKIT_ENUM_TYPES_H

• Component: WebKitGTK
• Status: RESOLVED WONTFIX

[Alberto Garcia]

I'm having this build failure with WebKitGTK+ 2.17.5, and it has also been reported with 2.16.6:

   In file included from Source/WebKit/UIProcess/API/glib/WebKitCookieManager.cpp:26:0:
   obj-aarch64-linux-gnu/DerivedSources/webkit2gtk/webkit2/WebKitEnumTypes.h:27:0: error: unterminated #ifndef
    #ifndef WEBKIT_ENUM_TYPES_H

That header is incomplete, and that happens because glib-mkenums fails
when generating it with the following error:

   Traceback (most recent call last):
     File "/usr/bin/glib-mkenums", line 669, in <module>
       process_file(fname)
     File "/usr/bin/glib-mkenums", line 406, in process_file
       line = curfile.readline()
     File "/usr/lib/python3.5/encodings/ascii.py", line 26, in decode
       return codecs.ascii_decode(input, self.errors)[0]
   UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 3887: ordinal not in range(128)

My locale is set to POSIX, and that's probably why this fails (reminds
me of bug 128971). The problem here is that the program this time is
glib-mkenums, so we cannot apply the same solution (unless we report
the problem there).

It looks like the non-ascii character that is causing trouble is this
'—' in WebKitWebContext.h:

   of web views and the content of in each must not interfere with the
   rest — for example a full-fledged web browser with support for
   multiple tabs.

so perhaps replacing it with an ascii '-' is enough to fix this. I'll
check it and come back with my findings.

[Jeremy Bicha]

The Debian bug for that issue is

https://bugs.debian.org/870310

It's a regression caused by Debian unstable upgrading to glib 2.53.4. I believe the issue is already fixed in glib git master so it should be fixed in glib 2.53.90 next week.

[Alberto Garcia]

I see, thanks!

The question is: why doesn't the WebKit build fail immediately if
glib-mkenums doesn't succeed? It doesn't make sense to carry on with
the build in a scenario like this one.

If someone knows enough cmake to fix this it would be nice, else I
guess we can close this bug.

[Michael Catanzaro]

This is indeed fixed in GLib git master.

(In reply to Alberto Garcia from comment #2)
> I see, thanks!
> 
> The question is: why doesn't the WebKit build fail immediately if
> glib-mkenums doesn't succeed? It doesn't make sense to carry on with
> the build in a scenario like this one.

I'm not sure, but I think it's possibly returning a success code. The build failures we had in GNOME this week were equally-obtuse, they wound up looking like ordinary build races (from failing to add the generated headers to BUILT_SOURCES) and you only see the real failure if you scroll up.

Anyway, I haven't investigated; anyone should of course feel free to improve the CMake build if improvements are possible.