GNOME Bugzilla – Bug 642601
Library public header generation : missing header inclusion from custom VAPI
Last modified: 2018-05-22 13:54:45 UTC
I am currently developping a library using vala. This library depends on a local packages declared by a VAPI file within the source tree. The library compilation goes fine, but the generated header misses the inclusion of the header declared in the VAPI file while using internally some constants from this header. So any code linking to my library will fail to compile. My library is compiled with the following flags : libw3cwidgets_la_VALAFLAGS = -v -g --library w3c-widgets -H w3c-widgets.h --pkg gio-2.0 --pkg libxml-2.0 --pkg gee-1.0 --pkg libsoup-2.4 --pkg uuid --vapidir ./util Where 'uuid' package is the internal package at fault. Its VAPI is found in 'util/uuid.vapi' The library compilation is successful. The program linking to the library is compiled with: w3c_widgets_test_VALAFLAGS = -g --pkg gio-2.0 --pkg libxml-2.0 --pkg gee-1.0 --pkg libsoup-2.4 --vapidir $(top_builddir)/src/util --vapidir $(top_builddir)/src/ --pkg w3c-widgets --pkg uuid resulting in the following gcc errors : ../src/w3c-widgets.h:639:34: erreur: ‘UUID_VARIANT_NCS’ undeclared here (not in a function) ../src/w3c-widgets.h:640:34: erreur: ‘UUID_VARIANT_DCE’ undeclared here (not in a function) ../src/w3c-widgets.h:641:40: erreur: ‘UUID_VARIANT_MICROSOFT’ undeclared here (not in a function) ../src/w3c-widgets.h:642:36: erreur: ‘UUID_VARIANT_OTHER’ undeclared here (not in a function) ../src/w3c-widgets.h:646:32: erreur: ‘UUID_TYPE_DCE_TIME’ undeclared here (not in a function) ../src/w3c-widgets.h:647:34: erreur: ‘UUID_TYPE_DCE_RANDOM’ undeclared here (not in a function) Those constants are indeed defined in <uuid/uuid.h> and $ grep 'uuid/uuid.h' src/w3c-widgets.h $ So it seems the header generation "forget" to include this header in my library's public header file. I dont know if it is a bug in my VAPI file or a codegen one. Help :) The related VAPI file can be read at http://pastebin.com/ctecE1JF The library full source can be checked at https://github.com/amazari/lib-w3c-widgets. (Dont try to run it, it fails miserably at present time :)) Thanks !
Created attachment 265430 [details] Testcase Encountered a similar issue and wrote a minimal testcase. Compile my attachment with "valac -H headertest.h -C headertest.vala". The resulting headertest.h should contain the line "#include <sys/socket.h>" but it does not. Even adding '''[CCode (cheader_filename = "sys/socket.h")]''' does not change that.
(In reply to comment #1) > Created an attachment (id=265430) [details] > Testcase > > Encountered a similar issue and wrote a minimal testcase. Compile my attachment > with "valac -H headertest.h -C headertest.vala". The resulting headertest.h > should contain the line "#include <sys/socket.h>" but it does not. > > Even adding '''[CCode (cheader_filename = "sys/socket.h")]''' does not change > that. Of course you have to add "--pkg posix" to the valac arguments. Forgot that... Sorry
This is the correct behavior. Vala emits #include when you actually use a symbol. cheader_filename is for those using your symbols. If you write a .vala that uses your enum, you'll see in your application the #include.
For what concerns the original bug, is it probably because UUID_VARIANT_MICROSOFT & co do not exist at all? In which case your vapi is the fault.
Created attachment 265682 [details] More complex testcase This might be a misunderstanding on my side, but I do not think that this is correct behavior The attached tarball contains a little testproject that contains: a) a simple library (hello.c) that exposes its api via hello.h b) a vapi-file (hello.vapi) that exposes the api from hello.h to vala c) a wrapper-library for libhello.so written in vala (hellowrapper.vala) that exposes its vapi via hellowrapper.vapi and hellowrapper.h d) a program that uses libhellowrapper.so (hellouser.vala) e) a Makefile obviously This should work, but it does not. Compilation of hellouser fails. The generated hellowrapper.h should include hello.h or resolve the constants HELLO and GOODBYE to their numerical values. If this is in fact correct behavior i need a way to work around this issue.
Ok now that's more clear. Yes that's a compiler bug. Your workaround is -X -include -X hello.h, or use numbers manually.
As https://wiki.gnome.org/Projects/Vala/Hacking does not have a section about codegen yet... Do you have a few pointers on how to fix this? :)
No idea, eheh. However, if it was a parameter with type Foo, where Foo is from hello.vapi, that would automatically require the relevant .h. You might try to see if this works already. I can't point you to a specific line in the code, otherwise I would have fixed it already :-). However you can search for all cheader_filename usage in the codegen, that's a starting point.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/vala/issues/167.