Summary: | WebKitEnumTypes.h:27:0: error: unterminated #ifndef WEBKIT_ENUM_TYPES_H | ||
---|---|---|---|
Product: | WebKit | Reporter: | Alberto Garcia <berto> |
Component: | WebKitGTK | Assignee: | Nobody <webkit-unassigned> |
Status: | RESOLVED WONTFIX | ||
Severity: | Normal | CC: | bugs-noreply, jbicha, mcatanzaro |
Priority: | P2 | ||
Version: | WebKit Nightly Build | ||
Hardware: | Unspecified | ||
OS: | Unspecified |
Description
Alberto Garcia
2017-08-01 12:10:30 PDT
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. |