Re: Patch: gtk peer - native code merge

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Michael" == Michael Koch <konqueror@gmx.de> writes:

Michael> I wrote the attached patch to merge the native part of the
Michael> GTK peer with GNU classpath.
Michael> Okay to commit ?

I'll let Tom and/or Graydon speak to this one, but...

Michael> +void menu_pos (GtkMenu *, gint *, gint *, gboolean *, gpointer);

I'd like to advocate a rule that all functions in the Gtk peers are
either:

* Direct implementations of native methods, named with appropriate
  JNI mangling, or
* Have a classpath-specific name (i.e., we pick some prefix that is
  clear and unambiguous like "classpath_" or "cp_gtk_"), or
* are static

So if `menu_pos' is not used elsewhere, we would make it static.
If it is used elsewhere, we would rename it.

I think the above represents a pretty standard rule for library
development.  We need to be able to dlopen() our Gtk peers into an
unknown environment (the vm could load any number of other libraries
as well), so it pays for us to be careful here.

It isn't too hard to automate checking for this.  A long time ago we
used to use the code in `maintainer-check' to do this for some other
parts of libgcj (that code is pretty much dead at this point, but it
could serve as a starting point for peer-checking code).

Tom