Re: linkification warnings

On Fri, Dec 18, 2009 at 07:42:00PM +0100, Nicola Fontana wrote:
> Il giorno Fri, 18 Dec 2009 16:24:28 +0100
> David Nečas <yeti physics muni cz> ha scritto:
> > On Fri, Dec 18, 2009 at 02:58:10PM +0100, Nicola Fontana wrote:
> > > Il giorno Fri, 18 Dec 2009 13:18:02 +0100
> > > David Nečas <yeti physics muni cz> ha scritto:
> > > 
> > > > 1) A few of my objects have some public, documented fields.  They
> > > > are marked /*<public>*/ and they appear correctly in the docs.
> > > > But I cannot link to them.
> > > 
> > > I think the problem is the link to a struct that is subclassing a
> > > GObject is renamed to MyStructName+"_struct" [1] (resulting in
> > > MyStructName-struct after the id mangling).
> > > 
> > > If this is the case, using #GwyField-struct.xreal should work
> > 
> > You are right, adding -struct fixed it, thanks.
> As a side note, from the sources it seems not only GObject structs are
> treated differently, but any struct in the *.hierarchy file (so anything
> with a _get_type() function present in *.types, I suppose).

Not everything with _get_type() ends up in .hieararchy.  I'd like my boxed
types to be listed there as derived from GBoxed -- and their _get_type()
functions put to <SUBSECTION Standard>, but that does not happen, at
least for me.

Also, for some reason FooClass does not end up in -sections.txt
generated with --rebuild-sections.  I'm not sure if it's my fault or
a policy to exclude them or a bug (AFAICT when gtk-doc generated
-sections.txt it has never put FooClass there so it might be a policy).
I add them with a script at present to be able to document virtual

> Some time ago I provided a patch to _optionally_ append prefixes to any
> type unconditionally ("-struct" to any struct, "-union" to any union
> and so on) but it is still waiting review:
> This would always permit to have a page with the same name of a type,
> allowing for example to have:
> instead of:
> Actually, this is not possible to do.

Yes, that would be nice.  It's one of the main reasons why I requested
(and possibly implemented, maybe Stefand did it) @section_id.
Unfortunately, it can't be used for this purpose due to the id clash.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]