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