175040 2017-08-01 12:10:30 -0700 WebKitEnumTypes.h:27:0: error: unterminated #ifndef WEBKIT_ENUM_TYPES_H 2017-08-01 15:16:26 -0700 1 1 1 Unclassified WebKit WebKitGTK WebKit Nightly Build Unspecified Unspecified RESOLVED WONTFIX P2 Normal --- 1 berto webkit-unassigned bugs-noreply jbicha mcatanzaro oldest_to_newest 1333885 0 berto 2017-08-01 12:10:30 -0700 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. 1333895 1 jbicha 2017-08-01 12:19:42 -0700 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. 1333916 2 berto 2017-08-01 13:01:48 -0700 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. 1333976 3 mcatanzaro 2017-08-01 15:16:26 -0700 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.