GNOME Bugzilla – Bug 697777
internal fields appear in public header/struct
Last modified: 2018-05-22 14:45:56 UTC
Until recently, libfolks-telepathy had this: public class Tpf.PersonaStore : Folks.PersonaStore { ... internal SmallSet<string> _supported_fields; internal Set<string> _supported_fields_ro; ... } When compiled without using --internal-vapi or --internal-header, this results in the C struct in the public header looking like this: struct _TpfPersonaStore { FolksPersonaStore parent_instance; TpfPersonaStorePrivate * priv; FolksSmallSet* _supported_fields; GeeSet* _supported_fields_ro; }; and the header from the .vapi for FolksSmallSet being #include'd. Unfortunately, FolksSmallSet is declared in a header that isn't installed (it's a private C implementation of Gee.Set optimized for small or empty sets), so this broke the build of dependent projects. Ideally, adding "internal Foo" to a class shouldn't result in changes to the public header (although I can't really see a way to to achieve that).
(In reply to comment #0) > Ideally, adding "internal Foo" to a class shouldn't result in changes to the > public header (although I can't really see a way to to achieve that). Since the internal classes can have access to *Private it should be possible to put internal symbols there (If you already have symbols defined such change would change the ABI).
Created attachment 253051 [details] [review] Preliminary support for hiding internal instance members This is not yet working for multiple files as the code generation for Private needs to be altered.
-- 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/373.