After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 642601 - Library public header generation : missing header inclusion from custom VAPI
Library public header generation : missing header inclusion from custom VAPI
Status: RESOLVED OBSOLETE
Product: vala
Classification: Core
Component: Code Generator
unspecified
Other Linux
: Normal major
: ---
Assigned To: Vala maintainers
Vala maintainers
Depends on:
Blocks:
 
 
Reported: 2011-02-17 18:02 UTC by Alexandre Mazari
Modified: 2018-05-22 13:54 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Testcase (203 bytes, text/x-vala)
2014-01-06 12:28 UTC, Richard Wiedenhöft
Details
More complex testcase (1.00 KB, application/x-bzip)
2014-01-08 10:31 UTC, Richard Wiedenhöft
Details

Description Alexandre Mazari 2011-02-17 18:02:54 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 !
Comment 1 Richard Wiedenhöft 2014-01-06 12:28:42 UTC
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.
Comment 2 Richard Wiedenhöft 2014-01-06 12:30:35 UTC
(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
Comment 3 Luca Bruno 2014-01-06 18:32:06 UTC
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.
Comment 4 Luca Bruno 2014-01-06 18:34:09 UTC
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.
Comment 5 Richard Wiedenhöft 2014-01-08 10:31:26 UTC
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.
Comment 6 Luca Bruno 2014-01-08 10:46:15 UTC
Ok now that's more clear. Yes that's a compiler bug. Your workaround is -X -include -X hello.h, or use numbers manually.
Comment 7 Richard Wiedenhöft 2014-01-09 09:30:57 UTC
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? :)
Comment 8 Luca Bruno 2014-01-09 09:35:51 UTC
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.
Comment 9 GNOME Infrastructure Team 2018-05-22 13:54:45 UTC
-- 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.