Re: Gnome2-VFS

[Ross McFarland <rwmcfa1 neces com>]

On Mon, 2004-06-14 at 19:02, muppet wrote:
> On Monday, June 14, 2004, at 05:07 PM, Ross McFarland wrote:
>
> > possible solutions:
> >     - modify perl-Gnome2-VFS.spec.in to buildrequires gtk2-devel
>
> i don't think this is necessary.

i don't like it either, but it's fix this or do something else.

> >     - modify Gnome2-VFS and/or Gtk2 so that gtk/gtk.h isn't needed to 
> > build Gnome2-VFS.
>
> just VFS.  it doesn't need to include gtk.h.  in fact, i thought we'd 
> already fixed that.  :-/

it includes gtk2perl.h which inclues gtk/gtk.h. it needs neither,
including gperl.h is sufficent. (along with replacing Gtk2 with Glib in
the EU::D call)

> > the second case could have larger implications as in the codegen stuff 
> > probably shouldn't be part of Gtk2 etc, but i don't know about that.
>
> the problem is that Gtk2::CodeGen special-cases GtkObject, and that 
> makes its code inappropriate for going into Glib.
>
> GtkObjects need to be sunk, so gtk2perl_new_gtkobject() always calls 
> gperl_new_object() with "own" set to true.  thus, CodeGen needs to know 
> to treat GtkObjects differently and there's no way around it.
>
> i suppose we could have an extensible Glib::CodeGen, to which 
> Gtk2::CodeGen would add its own types.  then packages like Gnome2::VFS 
> could just use Glib::CodeGen directly, and other packages which also 
> add "unique" semantics to GObject could be supported quite easily.
>
> on the other hand, i've never committed a code generator to Glib 
> because i wasn't happy with the generation techniques of Gtk2::CodeGen. 
>   it gets the job done, but it's not as elegant and extensible as it 
> could be.  ...not that i really want an xml type spec, but still.

this is all kinda murky, i don't really think it's worth splitting
things out at this point, but if we were starting from scratch it would
be a good idea to do something like this. 

the issue that '-I build' is being added to the CFLAGS of all of the
Gtk2 dependent modules via EU::D. needs to be addressed. i don't like it
b/c -I build is just magically being added by someone else and the
module is making use of it. i would prefer that it was added explicitly
in each module that uses the build directory or ...

we do need to change something here. is the solution to not add -I build
at all and prefix all of the autogen'd headers with build/? i don't see
an issue with doing this, in fact i kinda like it. doing so was my test
solution with Gnome2::VFS. apparently the toplevel of the module is put
in the include path by something. and doing build/vfs2-autogen.h etc.
works fine.

-- 
-rm