Re: more gnome 2 proposal

[Alex Graveley <alex ximian com>]

On 11 Mar 2001 01:26:17 -0500, Havoc Pennington wrote:
> 
> Alex Graveley <alex ximian com> writes: 
> > My personal view is that this is a major mistake. You run the risk of
> > continuing the tradition of difficult builds and complex
> > dependencies.
> 
> Nah - if all you want is one big tarball, it's trivial to make a
> toplevel Makefile that builds all the subtarballs using
> AC_CONFIG_SUBDIRS(). That's a quick weekend hack.


Of course, but I could just as easily write a script to split a large
tarball into smaller ones, and that would be almost as useless.


> Also, I would point out:
>  - most people use packages


Exactly my point in wanting to minimize having multiple versions of
packages floating around on systems considered "current". 


>  - we already have so many dependencies to build say Nautilus that 
>    this gnome-libs breakup is barely a drop in the bucket


Hmm, things are already bad so lets just add more wood to the fire?


> The reason builds are historically difficult is that stuff does not
> build and APIs keep changing. Tinderbox, branches, and decent release
> practice chills that out a good bit. We are also not chasing a moving
> GTK this time, hopefully.


IMO the things that keep builds difficult are having to have 12
libraries in 12 separate packages up to date with eachother. Unless of
course the thing you are trying to build requires a certain version or
branch of something else, and end up keeping between 2 and 4 versions of
that thing and its dependencies in source form, with different build
target directories, yadda yadda.

Besides, having a single makefile to check that everything compiles will
work a hell of a lot better than a tinderbox (not to say that we
shouldn't have one anyways :-).

Also having a single buildable module means that gnome 2.0 development
will not be blocking on things like setup, configuration, and
maintenance of a tinderbox.


> > Keeping everything in one or two modules is nearly guaranteed to fix
> > both problems.
> 
> And introduce a host of more serious ones. We can do a virtual module
> that sucks in a bunch of submodules and has a toplevel makefile, in
> fact a script to do that is a requirement for Tinderbox.


Could you please list those more serious problems?


> > What this does mean is that development for Gnome becomes a hard
> > target for third-parties. You would be able to develop against the
> > currently released frozen Gnome API, not whichever API is current
> > for a module, or whichever version of packages a given distibution
> > decides to ship.
> 
> All the libs freeze at once and remain so, they are not allowed to
> vary independently. That's how it works even today for libs that have
> been released for 3rd party use.
> 
> Empirically, gnome-libs has been a huge disaster, while lots of small
> separately-maintained modules such as ORBit and libxml and gnome-vfs
> and gdk-pixbuf have done relatively well. In my view the problem with
> gnome-libs is that it has no clear statement of purpose or function,
> and no person doing full-time or sufficient-time work on it. It's just
> a place where random people have dumped random stuff. One way to fix
> the mess is to create individual modules with clear purpose, clear
> function, and clear babysitters.


And libgnome-2 in your proposal is different from gnome-libs how?

Anyways, I think this problem with gnome-libs exists purely because of
its being a separate package. I think this is because keeping gnome-libs
has had an out-of-sight-out-of-mind effect. This would not be the case
for a large, nicely integrated tree.


> I would also point out the "Imlib problem" or "GtkXmHTML problem"
> which is that tightly integrating everything has nasty consequences if
> you decide one of the things was broken and should be replaced.


I think keeping things separate would in no way have help situations
like these.


> Of course I can also refer you to my previous Dependency
> Manifestos. ;-)
> 
> We can use pkg-config and its dependency/conflicts mechanisms to
> enforce a single platform; for example it can have a "gnome-2.0"
> module including all the libs, or it can have conflicts with versions
> greater than or less than a given number. App developers really don't
> have to know about how many shared libs or packages are involved here,
> and they can get nice warnings if they mix-and-match versions
> inappropriately.


This could work, yes, but there is no need for it wrt core libraries
given one large tree.


> Finally I'll whine about build time for a single package - fixing a
> bug in gnome-libs is an enormous PITA, because rebuilding that bastard
> takes ages already. Add a few new big libs in there...


Again, we could separate the module into logical libraries and packages
as we see fit; for instance, to keep build times reasonable.

-Alex

-- 
 make: *** No rule to make target `sense'.  Stop.