This appears to be because tpf-persona-store.vala has

  internal SmallSet<string> _supported_fields;

and the need for the header leaks into our public API, even though the symbol itself is (allegedly) 'internal'. Thanks, Vala, you've been invaluable...

I don't think we want to install <folks/small-set.h> as API at this stage (particularly because it's difficult to use from out-of-tree Vala code!) but this can be avoided by either redeclaring that member as a Set, or making it private: either

  private SmallSet<string> _supported_fields;

or

  internal Set<string> _supported_fields;

(It doesn't seem to be used elsewhere in the Folks tree, at least according to grep, so private is fine from that perspective.)

Philip, which would you prefer?

(In reply to comment #1)
> This appears to be because tpf-persona-store.vala has
> 
>   internal SmallSet<string> _supported_fields;
> 
> and the need for the header leaks into our public API, even though the symbol
> itself is (allegedly) 'internal'. Thanks, Vala, you've been invaluable...

Sigh. Please file a Vala bug about it. At the very least Vala should be emitting a warning about how internal headers are being leaked.

> Philip, which would you prefer?

Please make it private (and also _supported_fields_ro). It should never have been ‘internal’ — only the supported_fields property needs to be ‘internal’ (and should be safe as such because it has type Set<string>).

A quick search throws up bug #694809 which isn’t the right bug, but does suggest we should be passing --internal-header=tpf-persona-store-internal.h (or similar) to Vala. That might be a good idea. In any case, those two variables should be private.

*** Bug 697763 has been marked as a duplicate of this bug. ***

(In reply to comment #2)
> Please make it private (and also _supported_fields_ro). It should never have
> been ‘internal’ — only the supported_fields property needs to be ‘internal’
> (and should be safe as such because it has type Set<string>).

Done, commit c6c0635. This is technically an ABI break for subclasses, because the resulting C struct is 2*sizeof(void*) bytes shorter now - do we support subclasses of TpfPersonaStore? If we do, we'll need to add "internal void *? _pad1 = null; internal void *? _pad2 = null;" or something, to get back to the original size. If we don't care about subclasses of that class, this can be skipped, though.

(Also technically an API break for C because someone could conceivably have been looking at the struct members, but given that they're explicitly internal, I'm more comfortable with declaring this to be not-a-bug.)

I wonder whether Vala ought to have a Java-style "final" keyword which omits the public struct from the header entirely, for objects that really shouldn't be subclassed - it could even make constructor() or constructed() assert(type == OUR_TYPE).

> Sigh. Please file a Vala bug about it. At the very least Vala should be
> emitting a warning about how internal headers are being leaked.

Bug #697777 (although note that Vala has no way to know that small-set.h is meant to be internal, really).

(In reply to comment #4)
> (In reply to comment #2)
> > Please make it private (and also _supported_fields_ro). It should never have
> > been ‘internal’ — only the supported_fields property needs to be ‘internal’
> > (and should be safe as such because it has type Set<string>).
> 
> Done, commit c6c0635. This is technically an ABI break for subclasses, because
> the resulting C struct is 2*sizeof(void*) bytes shorter now - do we support
> subclasses of TpfPersonaStore? If we do, we'll need to add "internal void *?
> _pad1 = null; internal void *? _pad2 = null;" or something, to get back to the
> original size. If we don't care about subclasses of that class, this can be
> skipped, though.

I don’t think it’s necessary to add padding. We don’t have an official policy on external subclasses, but we strongly discourage people (for example) instantiating PersonaStores manually, and I think this falls in the same general area.

> I wonder whether Vala ought to have a Java-style "final" keyword which omits
> the public struct from the header entirely, for objects that really shouldn't
> be subclassed - it could even make constructor() or constructed() assert(type
> == OUR_TYPE).

Bug #669541, apparently.