Created attachment 123713 [details] [review]
Custom is pointer function extension patch

Could I see an example of how this would be used, please.

It would be used from the extra defs generation utility of the module.  For example the genereate_defs_gst.cc would look partly like:

#include "glibmm_generate_extra_defs/generate_extra_defs.h"

#include <gst/gst.h>

bool gst_type_is_a_pointer(GType gtype)
{
  return (gtype_is_a_pointer(gtype) || g_type_is_a(gtype, GST_TYPE_MINI_OBJECT));
}

...

int main (int argc, char* argv[])
{
...
  std::cout << get_defs(GST_TYPE_BUFFER, gst_type_is_a_pointer)
            << get_defs(GST_TYPE_CAPS, gst_type_is_a_pointer)
...
}

However, I just looked and it is not necessary for what I'm trying to do (get the right types of properties and signals for plug-ins that are to be generated).  At first I sort of got somewhat confused and thought this was needed, but it really is not.  It still can be used as described above, but a local function for determining if a type is a function will work fine without the need for this patch.  Sorry for the confusion.

> a local function for determining if a type is a function will work fine without
> the need for this patch.

I'd be interested to see that when you do it.

Thanks.

Okay.  Plug-in generation is well underway so it can be said that it's pretty much functioning.  When generating plug-ins, however, we have two options when dealing with the plug-in defs:

1) Generate them prior to the build process (in the jhbuild environment) so that the defs are contained in the signal defs file (the extra defs) or:

2) Generate them as the plug-ins are generated in the build process and then use the generated defs when the generated plug-in sources are processed by gmmproc.

I think 2) is more advantageous because it allows the build process to deal correctly with possible differences in how plug-ins are defined in different versions.  One such example plug-in is audioresample[1].  In jhbuild its type is named GstSpeexResample while in version 0.10.20 its type is GstAudioResample.

When the defs are generated in jhbuild, the type name `GstSpeexResample' is used for the defs, but when the plug-in is generated outside of jhbuild, using version 0.10.20 of the GStreamer libraries, then the defs are not found for the type, GstAudioResample.

If the defs are generated during the build process, the defs will always be found for the available plug-ins on the build system.  However, this patch would be needed so that the pointer types are always correctly identified because defs generation would be done on the fly and not supervised so no patching could be done to the defs then.

In the audioresample example above the signals and properties are not modified, but the type name is different, which, as a side note, brings up any ABI issues that things like this may cause.

[1] http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-base-plugins/html/gst-plugins-base-plugins-audioresample.html

(In reply to comment #3)
> bool gst_type_is_a_pointer(GType gtype)
> {
>   return (gtype_is_a_pointer(gtype) || g_type_is_a(gtype,
> GST_TYPE_MINI_OBJECT));
> }
> 
> ...
> 
> int main (int argc, char* argv[])
> {
> ...
>   std::cout << get_defs(GST_TYPE_BUFFER, gst_type_is_a_pointer)
>             << get_defs(GST_TYPE_CAPS, gst_type_is_a_pointer)
> ...
> }

Ah, so this is to detect GstMiniObjects, which don't use the normal GObject GType system. Sounds good. Feel free to commit that if you need it.

> However, I just looked and it is not necessary for what I'm trying to do 

Now I am a little confused. Do you need this or not?


> 2) Generate them as the plug-ins are generated in the build process and then
> use the generated defs when the generated plug-in sources are processed by
> gmmproc.

We generally generate .defs infrequently and by hand. That makes everything much less fragile - for instance the API doesn't change silently depending on what happenes to be on the PC of the person making the tarball. I'd like to keep it that way.

(In reply to comment #6)
> Ah, so this is to detect GstMiniObjects, which don't use the normal GObject
> GType system. Sounds good. Feel free to commit that if you need it.
> 
> > However, I just looked and it is not necessary for what I'm trying to do 
> 
> Now I am a little confused. Do you need this or not?

Sorry.  I wasn't sure if it was needed when I first submitted the report.  After, I realized that I could do without it because I could just patch the defs files after manual generation.

> > 2) Generate them as the plug-ins are generated in the build process and then
> > use the generated defs when the generated plug-in sources are processed by
> > gmmproc.
> 
> We generally generate .defs infrequently and by hand. That makes everything
> much less fragile - for instance the API doesn't change silently depending on
> what happenes to be on the PC of the person making the tarball. I'd like to
> keep it that way.

For clarity, now I'm back to not needing it because the defs files can still be patched if the defs are generated by hand, but since it makes things easier (less patching necessary), with your permission, I think I'll apply it.

Sorry once more for lack of clarity:

2008-12-16  José Alburquerque  <jaalburqu@svn.gnome.org>

	* tools/extra_defs_gen/generate_extra_defs.cc:
	* tools/extra_defs_gen/generate_extra_defs.h: Modify extra defs
	generation utility to accept custom defined function to determine if
	GType is a pointer.