Created attachment 74439 [details] [review]
proof of concept patch

To get somewhere with this, I attached a simple yet working patch (against CVS HEAD).

The patch does not get rid of foo.types fully, instead, it generates it.  And it generates it only if nonempty foo.includes (see below) is found, so it should be backward-compatible.

The file is written by gtkdoc-scan which has everything necessary for this job.  It works for me to the extent I could start using it right away, however there are some issues:

* gtkdoc-scan has to be run before gtkdoc-scangobj.  This is not how
  gtk-doc.make works now, but I cannot see anything in gtkdoc-scan that could
  depend on gtkdoc-scangobj therefore I assume they can be just switched.
  It seems to work for me.

* foo.types needs also some #includes.  While simply adding #includes for
  all header files we actually process in gtkdoc-scan would work for me, it
  can be perhaps too brutal for some projects with broken header files.  So
  I added foo.includes which is put before the generated content in foo.types.
  But I would be glad to generate the #includes too.

* gtk-doc.make needs more updates: foo.includes has to be added to dists,
  created empty on the first run, and made a dependency of the scan phase.
  I haven't done this as it would be waste of time if the gtkdoc-scan part
  got shot down.  What's worse is that we do not know whether foo.types is
  a maintainer-cleanable file or not.

Generating #includes should not be necessary unless you want to verify the get_type() functions are present (directly or indirectly) in those files.

Simple 'extern GType foo_get_type(void);' should be sufficient declaration that can easily be autogenerated.

Created attachment 74443 [details] [review]
proof of concept patch

OK, a new patch with automatic declarations.

Since we have no other indication whether to rebuild foo.types now (no foo.includes), it adds explicit --rebuild-types option to gtkdoc-scan.

gtkdoc-scangobj generates the automatic declarations iff there is no #include line in foo.types.  This should work with both manually created foo.types (either with existing #includes or without) and generated foo.types (that have no #includes).

Created attachment 74494 [details] [review]
proposed patch

An improved patch.

In addition to the previous one:

* the order of gtkdoc-scan and gtkdoc-scangobj execution in gtk-doc.make is
  exchanged

* gtkdoc-scan writes foo.types also if it does not exist at all so that one
  gets something reasonable the first time the whole thing is run

I've applied this with a slight change - it was only adding the first
*_get_type() function found in a header file, so I changed it to add all of them.

Let me know if I broke it. (It seems to work fine for me.)

Well, it does not do the same.

My patch indeed took only the first declaration, this was wrong.  However it output only get_type()s of classes and interfaces.  The current CVS HEAD happily puts *every* get_type() it finds to foo.types.  This leads to

(process:30810): GLib-GObject-CRITICAL **: g_object_class_list_properties: assertion `G_IS_OBJECT_CLASS (class)' failed

if the get_type() belongs to a boxed type or enum.  The test whether the type has a FOO_IS_* must be reintroduced somewhere -- although I admit I'm getting lost in sub ScanHeader so I'm not sure where.

Another possibility is to make foo-scan.c smarter and skip non-object types -- for example by setting the GTypes to 0 for non-object types in get_object_types() and testing for nonzero in place where object_types[] is used.  I can do this.

Scratch the previous comment, it seems I was running mismatched versions of gtkdoc-scan and gtkdoc-scangobj.  It does output every get_type(), but the scanner can handle it.  So it seems OK.

There is one problem. With no includes in .types and me using
SCANGOBJ_OPTIONS=--type-init-func="g_type_init();gst_init(&argc,&argv)"

it fails to locate gst_init().

(In reply to comment #8)
> There is one problem. With no includes in .types and me using
> SCANGOBJ_OPTIONS=--type-init-func="g_type_init();gst_init(&argc,&argv)"
> 
> it fails to locate gst_init().

You can do

--type-init-func="void gst_init(int*,char**);g_type_init();gst_init(&argc,&argv)"

Except that now $TYPE_INIT_FUNC is put after

  if (argv != argv) argc = argc;

It should go before it to allow declarations in $TYPE_INIT_FUNC (gcc and other C99 compilers accept them, but why try the compiler...).

Good idea! This infact works:

SCANGOBJ_OPTIONS=--type-init-func="do { void gst_init(int *argc,char **argv[]);g_type_init();gst_init(&argc,&argv); } while (0)"