Re: RFC: split gtk2-perl-xs

[muppet <scott asofyet org>]

On Sat, 2003-04-26 at 12:28, goran kirra net wrote:
> Think about distribution:
> * most users (and even most developers?) would not install by hand
>   but use packages binaries (rpm or deb or pkg etc).
>   These *must* be split or somebody wanting to install a glib2-based
>   package must though dependencies install gtkspell, lots of gnome 
>   libraries etc. 
> * most others will use CPAN or PPM, no problems
> * a few will install by hand.

make no bones about it --- i'm not a master of module packaging.  that's
why we're a team!  =)

for explanation of what's been done so far:

i have been splitting things into what i consider discrete modules under
the gtk2-perl-xs tree; e.g., Gtk2 gets a directory, Gnome2 gets a
directory, and GnomePrint2 gets a directory.  even though GnomePrint2
installs stuff into the Gnome2 namespace, i wanted to increase the
granularity of the build.  this was highly inspired by the old gtk-perl
package.

each of these directories could easily become a separate binary package
(which gtk=perl did *not* do).

the problem with breaking stuff up at the source level, and the reason
everything is currently in one tree, is the high degree of
interdependence in the build process.  this is the same thing with
gtk-perl --- all of the submodules use the same set of build tools, that
is, the helper scripts.

it would be easy enough to include genfirstpass.pl and genstuff.pl (both
with better names, of course) and Depends.pm (which wants to install
under ExtUtils::) in the G/Glib/whateverwecallit module.... however,
where should those helper scripts be installed?  i hesitate to put them
in $PREFIX/bin...  possibly we could use Depends to install them to
someplace under the perl lib tree (with the headers and typemaps).  I
was thinking of also adding a pkg-config wrapper module and putting some
of the autogen functionality into a module that could be used from a
Makefile.PL, which might clean this up a bit.


sound reasonable?  anyone have better or more elegant ideas?


once that's done, where do you want to go with it?  should we rename all
the toplevel directories to something distributable?  (this is the sort
of stuff with which i have little experience.)



> A 2nd argument is if gnome and spell goes in everything would just
> as well, gal, gail, eel, camel, print, printui, etc etc
> A big monolith makes maintenence difficult and release process.

i wanted to have stuff like Gnome2, GnomePrint2, and even GtkSpell in
the tree to work out how to chain modules together, and also to have
examples of how to create your own extension based on Glib/Gtk.  nothing
says they have to stay there.  as i've said in the past, i don't even
write gnome applications; my only interest is in ensuring that they are
possible and easy to create.



> We should not think of todays state of rapid development only,
> there will be days of maintenence.

that's a good segue.  i'd like to get into maintenance mode on gtk2 as
soon as possible, so i can *use* it rather than create it.  ;-)


> On the maintenence front, we probably want to release version 
> of gtk2-perl-xs before we have a mature enough gnome or spell or what-ever. 

before or after the module breakout?



> moving G:: -> GLib:: in CVS is a minor problem,
> just matter of a 
> # rm -f GLib2; ln -sf G GLib2
> at a strategic point in Makefile.PL

do you mean renaming in the build tree and leaving the name unchanged on
the CVS server?

-- 
muppet <scott at asofyet dot org>