On Wed, 2013-12-11 at 21:50 -0008, Jim Nelson wrote: > We've had a lot of trouble recently with building Geary due to some > flux with the WebKitGTK bindings and headers. Depending on the version > of WebKitGTK we're compiling against, we get errors like this: > > WebKit-3.0.gir:27733.7-27735.16: error: overriding method > `WebKit.DOM.TextTrackCue.dispatch_event' is incompatible with base > method `WebKit.DOM.EventTarget.dispatch_event': incompatible return > type. > > Which appears to be a problem with the WebKitGTK .gir, but causes valac > to issue an error and exit. (Note that our code doesn't use the > TextTrackCue class.) > > We use .metadata files to get around this problem: > > DOMTextTrackCue.dispatch_event type="void" > > However, if the symbol is unavailable in the .gir file (this particular > symbol was not available in earlier versions of WebKitGTK) valac issues > this warning: > > WebKit-3.0.metadata:16.1-16.16: warning: metadata never used > > ... which is treated as an error because we have fatal warnings enabled. > > There's multiple issues here, and not all of them Vala's, but I bring > them up because I think there may be one or two things Vala can do to > make life easier. I'm hoping to hear what others think before filing a > ticket. > > First, it seems that detecting an error in a .gir file shouldn't > necessarily cause a compiler error. The broader problem (in my mind) > is that the .gir file was generated in the first place, but so be it. > I think Vala should issue a warning in this situation, not an error. > But more specifically, I would prefer Vala not issue either a warning > or an error unless the faulty binding was causing a code generation > problem, i.e. the symbol was actually used by the .vala code. > > Second, is there any way Vala can ignore the .metadata problem, or at > least offer a command-line switch to enable/disable the warning? I > would really prefer not to have to disable fatal warnings to get around > this problem.
Don't use the GIR directly. GIRs take forever to parse anyways, why parse it every time you run valac? Use vapigen (without fatal warnings enabled) to parse the GIR to a VAPI, then use the VAPI. I would love to configure different errors/warnings to do different things (like you can with -ffoo, -fno-foo, -ffatal-foo for gcc). This wouldn't be particularly difficult to do with valac/libvala, it just needs a bit of light refactoring and some easy (but time-consuming) effort to enumerate, name, and maybe categorize every possible error. > I think the general problem is that there should be validation tools > that are stringent about checking (and producing) bindings and binding > metadata, but compilers should be looser about checking unless the > error or ambiguity is a problem for generating code. I disagree. By default the problem that vala really can't deal with intelligently (conflicting symbol) is an error, and the one it can deal with (unused metadata) is a warning, which seems quite reasonable to me. You're asking for fatal warnings, and you're getting what you ask for. -Evan
signature.asc
Description: This is a digitally signed message part
_______________________________________________ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
