If this is a shared library, it's not generally desirable to do so. What if the user wants to use both your library and the library you have re-exported? This will cause conflicts if there are any changes between the two versions.
More likely, you want to declare dependencies. This is done using a `.deps` file of the same name as your `.vapi` file. It lists the other packages on which you depend. The Vala compiler will automatically import them as if they were specified with the `--pkg` flag. There are plenty in `/usr/share/vala-*/vapi/*.deps`. For example, `webkit2gtk-4.0.deps` has the contents: gtk+-3.0 libsoup-2.4 If the library is static, then there really isn't a good mechanism. Any functions declared `public extern` in `.vala` will be exported, so you can migrate some of the VAPI to `.vala` files. You could also `cat` the two VAPIs together. This is pretty bad. I would probably convert the static library to shared and then use the `.deps` mechanism instead. On 21 November 2014 07:07, Andy Lees <andrewl...@gmail.com> wrote: > Hi, > > I would like to export an interface to some C structures from a vala > library that provides a number of other classes, etc. If I include the > vapi and associated .h file in the library, it compiles fine, but does not > export the contents of the referenced vapi in the library vapi. > > How would one go about including the vapi contents in the library > interface? > > Thanks for your attention. > _______________________________________________ > vala-list mailing list > vala-list@gnome.org > https://mail.gnome.org/mailman/listinfo/vala-list > -- --Andre Masella<an...@masella.name> http://www.masella.name/ _______________________________________________ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
