The Vapi file for WebKitGTK that ships with Vala is sorely out of date. It would be preferable for WebKitGTK to provide its own. A number of Vala applications rely on WebkitGTK (such a s Shotwell) so this addition would be much appreciated!
Any idea what the best practice is for shipping VAPI files with your library? Seems fairly simple to add a vapigen build step, we just need to install it somewhere.
I asked about this on the Vala mailing list. Marc-André Lureau responded with the following advice: ----------------------- This is what I would do if the vapi file can be generated directly from gobject-introspection gir file, then it's rather straightforward: Add --enable-vala and check for AC_PATH_PROG(VAPIGEN, vapigen) in configure.ac. Add vapi files rules in Makefile.am (perhaps in a vapi directory): if WITH_VALA vapidir = $(datadir)/vala/vapi vapi_DATA = \ webkit-1.0.vapi \ webkit-1.0.deps webkit-1.0.vapi: $(top_builddir)/where/to/find/WebKit-1.0.gir $(AM_V_GEN)$(VAPIGEN) --library webkit-1.0 $< endif Adjust your arguments where needed, add metadata/custum files etc.. Hope that helps!
It's also been pointed out on the mailing list that bug #49875 needs to be resolved (it includes a patch) before Vapigen can run properly on WebKitGTK.
Created attachment 123043 [details] Vapi generation files + script Here's a demo setup for generating the Vapi. I'm going to leave integrating all this into WebKitGtk's build system to the experts. How to use this: 1. Apply Evan's GIR patch. 2. Build and install WebKitGtk 3. Open my gen-vapi.sh script and comment out all but the first call to vala-gen-introspect. 4. Run the script. YOU WILL ENCOUNTER ERRORS. This is because the JavascriptCoreGtk headers reference .h files that vala-gen-introspect cannot find. The easiest thing to do here is to comment out those lines in the headers temporarily. 5. Uncomment the remaining lines in the script and run it again. Now you should have two shiny new .vapi files! Yay!
Created attachment 123452 [details] [GTK] Use uninstalled JSCore-3.0 package for creating WebKit-3.0.gir
Created attachment 123453 [details] [GTK] Add Vala bindings
(In reply to comment #4) > Created an attachment (id=123043) [details] > Vapi generation files + script This uses GIDL instead of GIR, which we (Vala) are in the process of moving away from.
Comment on attachment 123453 [details] [GTK] Add Vala bindings This looks pretty good to me. Do you mind moving new files into a 'vala' subdirectory?
Typically we do one patch per bug, but these two patches can probably just be combined.
Created attachment 123464 [details] Patch
I'm really glad to see the progress on this bug! My only concern is the metadata file still needs a few tweaks; Vala expects class names to be CamelCased in a certain way. Without the proper entries in the metadata, class names such as DOMElement result in gcc errors due to Vala's inability to match the class name to the appropriate type checking and casting macros.
Created attachment 123466 [details] Patch
(In reply to comment #11) > I'm really glad to see the progress on this bug! My only concern is the metadata file still needs a few tweaks; Vala expects class names to be CamelCased in a certain way. > > Without the proper entries in the metadata, class names such as DOMElement result in gcc errors due to Vala's inability to match the class name to the appropriate type checking and casting macros. Can you provide a minimal test case of something that doesn't work with the patch I just uploaded? If you're hitting GCC errors it sounds like a Vala bug, not an issue with the metadata.
I'll hold off my review here until Eric's response.
Unfortunately I still haven't been able to test this out. Over the weekend I found after a few hours that the WebKitGTK SVN repo is hosed; it always choked on some file with a mysterious error message. So today I checked it out with Git and everything seemed good. But I'm getting a compile error that appears related to this patch: Source/WebKit/gtk/webkit/webkitwebplugindatabase.h:51: Warning: WebKit: webkit_web_plugin_database_plugins_list_free: argument list: Missing (element-type) annotation GEN Programs/resources/inspector/inspector.html GEN Programs/resources/inspector/inspector.html GEN JSCore-3.0.typelib GEN WebKit-3.0.typelib GEN Source/WebKit/gtk/vala/webkitgtk-3.0.vapi /bin/bash: line 1: --library: command not found make[1]: *** [Source/WebKit/gtk/vala/webkitgtk-3.0.vapi] Error 127 make[1]: Leaving directory `/home/eric/Development/WebKit' make: *** [all] Error 2 Any idea what could be causing this?
I'm linking to this thread on desktop-devel-list because there is some minor controversy about whether including vapi files in the library is the way to go: http://mail.gnome.org/archives/desktop-devel-list/2012-January/msg00086.html I don't have much of an opinion on the matter, but it might be good to wait until the thread plays out.
(In reply to comment #15) > Unfortunately I still haven't been able to test this out. > > Over the weekend I found after a few hours that the WebKitGTK SVN repo is hosed; it always choked on some file with a mysterious error message. > > So today I checked it out with Git and everything seemed good. But I'm getting a compile error that appears related to this patch: > > > Source/WebKit/gtk/webkit/webkitwebplugindatabase.h:51: Warning: WebKit: webkit_web_plugin_database_plugins_list_free: argument list: Missing (element-type) annotation > GEN Programs/resources/inspector/inspector.html > GEN Programs/resources/inspector/inspector.html > GEN JSCore-3.0.typelib > GEN WebKit-3.0.typelib > GEN Source/WebKit/gtk/vala/webkitgtk-3.0.vapi > /bin/bash: line 1: --library: command not found > make[1]: *** [Source/WebKit/gtk/vala/webkitgtk-3.0.vapi] Error 127 > make[1]: Leaving directory `/home/eric/Development/WebKit' > make: *** [all] Error 2 > > > Any idea what could be causing this? Try installing vala from git master so you get the vapigen pkg-config file. If that resolves it I'll update the patch (just need to do PKG_CHECK_MODULES([VAPIGEN],[vapigen]) in configure.ac inside of the if test "$enable_vala" = "yes" block)
Running this with Vala from Git master is resulting in a very similar error: GEN WebKit-3.0.typelib GEN Source/WebKit/gtk/vala/webkitgtk-3.0.vapi /bin/bash: line 1: --library: command not found make[1]: *** [Source/WebKit/gtk/vala/webkitgtk-3.0.vapi] Error 127 make[1]: *** Waiting for unfinished jobs.... make[1]: Leaving directory `/home/eric/Development/WebKit' make: *** [all] Error 2
(In reply to comment #18) > Running this with Vala from Git master is resulting in a very similar error: > > > GEN WebKit-3.0.typelib > GEN Source/WebKit/gtk/vala/webkitgtk-3.0.vapi > /bin/bash: line 1: --library: command not found > make[1]: *** [Source/WebKit/gtk/vala/webkitgtk-3.0.vapi] Error 127 > make[1]: *** Waiting for unfinished jobs.... > make[1]: Leaving directory `/home/eric/Development/WebKit' > make: *** [all] Error 2 Did you pass --enable-vapigen when you built vala? Are you sure you installed it to the right prefix? From the error, it seems like the VAPIGEN variable is empty when it should point to the vapigen executable. It should be set to `pkg-config --variable=vapigen vapigen`, which requires the vapigen pkg-config file. If you're not installing to a standard location, you may need to use the PKG_CONFIG_PATH environment variable to make sure pkg-config is looking in the right location.
Success! Finally got it to build. And with your new metadata file my test program compiles and runs just fine. Problem wasn't with pkg-config, it was with the VAPIGEN variable. I had to set it manually, which I'm guessing was not the intention here. One question though -- what's the deal with JavaScriptCoreGTK? Is this not intended to be available to the outside world? (I'm new to WebKit so forgive my newb-ish question!)
Created attachment 123779 [details] [GTK] Add Vala bindings This version adds a pkg-config check for vapigen instead of just assuming it exists. Should fix the issue Eric is having (provided you accept "emits an error message during configure instead of a more cryptic one during build" as a valid definition of "fix").
(In reply to comment #20) > Success! Finally got it to build. And with your new metadata file my test program compiles and runs just fine. > > Problem wasn't with pkg-config, it was with the VAPIGEN variable. I had to set it manually, which I'm guessing was not the intention here. You shouldn't have to set it manually. It should be set for you using the vapigen pkg-config file, which I only added to Vala a few days ago. Can you try with the patch I just posted? If you need help getting it to work, stop by the #vala channel on gimpnet or #webkitgtk+ on freenode and ping me ("nemequ").
Evan, it works fine with your new patch. Looks good to me!
I think this patch is just waiting on approval from the WebKitGTK+ community at large. Would someone be willing to send a proposal to the webkit-gtk list with the reasons for doing this? I don't think there will be much opposition.
I discovered two errors in the Vapi today -- both are methods where the return type should be nullable: DOM.Document.get_element_by_id() DOM.Node.get_parent_element() There's probably a few similar functions that have the same issue.
(In reply to comment #25) > I discovered two errors in the Vapi today -- both are methods where the return type should be nullable: > > DOM.Document.get_element_by_id() > DOM.Node.get_parent_element() > > There's probably a few similar functions that have the same issue. Yes, that's likely true. See https://live.gnome.org/Vala/UpstreamGuide#Nullability_of_Return_Values Any functions with nullable return values should be fixed using the metadata file until G-I fixes the issue upstream, at which time the annotations will have to be modified. FWIW, the fix should be adding these two lines to the metadata file: DOMDocument.get_element_by_id nullable DOMNode.get_parent_element nullable
Not sure if this feature is still being considered or not, but I have another issue to report with the Vapi. It seems DOMEventTarget.add_event_listener() made it into the GIR file, but somehow doesn't appear in the Vapi. Evan, think you could take a look at that one? We're scratching our heads over this.
This is no longer needed. Newer versions of Vala can bind to GIR directly without needed a vapi. Some fixups ("metadata") are needed, however, but that seems like it belongs in the Vala project. For more info please see our ticket here: http://redmine.yorba.org/issues/6139