Re: [gtk-list] Re: Proposal: Split glib into a separate module

[Raja R Harinath <harinath cs umn edu>]

"Shawn T. Amundson" <amundson@completeis.com> writes:
> I see very little reason not to do this.
> 
> I think glib, when split off, should go straight to version 1.0.1 and
> all major changes to the library will be "officially" halted for the 
> 1.0 series.
> 
> One of the problems is that it would be very nice to keep the 
> commit/diff info on the glib files, which as I understand it, 
> is going to be almost impossible to do when we move it into 
> another module. ;-(

It depends on how the split is done.  If you just want a standalone glib
in addition to including it in gtk+, you can just put the following line
into CVSROOT/modules:

	glib gtk+/glib

and things should work fine. 

If however you want to remove glib from the gtk+ distrib, someone with
direct access (not just CVS write access, but login+write access) to the
cvs repository can just do a `mv glib ..' in the repository.  This way
will maintain all the commit/diff info, but can lead to `cvs update'
complaining -- nothing very serious.  Anyway, cvs always had trouble
with removing directories from the repository.

I have some reservations about it becoming 1.0, though.  It has to do
with the configuration/installation stuff.  The current setup has
problems with `glibconfig.h'.  Specifically:

	* It has problems building with $srcdir != $builddir
	* `glibconfig.h' should be installed somewhere in $exec_prefix, 
	  not in $includedir.
	* `glibconfig.h' pollutes the HAVE_* namespace of other
	  packages.  IMO, the HAVE_* symbols should come only from
	  a package's own configure run.

- Hari
-- 
Raja R Harinath ------------------------------ harinath@cs.umn.edu
"When all else fails, read the instructions."      -- Cahn's Axiom
"Our policy is, when in doubt, do the right thing."   -- Roy L Ash