GNOME Bugzilla – Bug 694809
valac does not respect internal header/vapi setting
Last modified: 2018-05-22 14:42:30 UTC
Hi! When I compile my project with --internal-header=foobar_internal.h --header=foobar.h --internal-vapi=foobar_internal.vapi, both headers are generated, as well as the internal Vapi file. However, the internal Vapi file references the non-internal header foobar.h, which of course causes problems later when symbols are not found. At time I solve this manually by postprocessing the generated internal Vapi using sed to replace the header reference. But it would be cool if this hack would not be needed and Vala would do the right thing if a combination of these flags is detected. Thanks! Matthias
I tried making Folks use --internal-header and --internal-vapi for Bug #697354, but because the internal header redeclares all the typedefs, that doesn't work as desired: each module can only include either the public header or the external header, never both. Folks' source tree has this structure (simplifying a bit): * libfolks (public shared library) * libfolks-telepathy (public shared library, links to libfolks) * Telepathy plugin (GModule, links to libfolks-telepathy and libfolks) If I use "--pkg folks" when building libfolks-telepathy, it can't see internal API from Folks (apart from "internal set" setters, for some reason), but if I use "--pkg folks-private" (where I compiled libfolks with --internal-vapi=folks-private.vapi), it gets folks-private in its .deps, and so cannot be used by third-party code once installed. Would it be possible to make the --internal-header be something that is used *as well as* the public header, and only contains the extra internal things? Then it would be safe to include both folks.h and folks-private.h. Similarly, would it be possible to make the internal VAPI result in the name of its public equivalent appearing in .deps?
Seconding Simon's request for an "internal-only" VAPI and header. Geary is building the following on a feature branch that is adding unit tests: * geary-engine library + internals * geary-client library * geary-engine-test executable (builds against geary-engine-internal) * geary-client-test executable (builds against geary-engine and geary-client) So geary-engine-test has access to geary-engine's internal's, which is super handy for creating mocks and running unit tests. But I can't do the same for geary-client-test, since it would redefine all of the engine's symbols to include both geary-engine.h (via geary-client.h) and geary-engine-internal.h. This means I can't use the same mock objects for testing the client as are used for testing the engine, and client test coverage is suffering as a result.
I was in the middle of the same issue with libgee's port to Meson, because internal header includes all symbols, public and internas, so redefinitions error are raised. For compatibility reasons a new switch should be added to produce both/each header and VAPI with just internals symbols, to be used with a --pkg switch on unit testing.
-- 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/358.