Re: gnome-recent (plans)

[James Henstridge <james daa com au>]

Anders Carlsson wrote:

> On Thu, 2002-07-04 at 05:13, Havoc Pennington wrote:
>  
>
> > I still wonder if we shouldn't install libegg, and protect it with
> > LIBEGG_I_KNOW_THESE_ARE_PROTOTYPES or something.
> >
> >    
>
> I'm not sure that's a good idea:
>
> * Many applications are just using one or two "features" from libegg. 
>
> * Installing the library means people are going to use it and depend on
> it, no matter how many #defines they have to put in their code :)
Maybe we should put the AC_DISABLE_SHARED macro into libegg's configure 
script?  This way it would only be a build time problem, rather than a 
runtime problem.  In fact, there would be no runtime dependence on 
libegg (which gets round the 20-libgals problem people seem to bring 
up).  We don't get the benefit of being able to upgrade the library to 
fix bugs in all apps that use it, but we don't have that with the 
current cut-n-paste model either.

> * It also means we have to make regular releases of libegg, which is
> more work for the maintainer(s).
At the same time, it is probably good to make sure that the various 
parts are buildable from tarballs :)

> * libegg is a highly unstable module that's guaranteed to break both API
> and ABI compat which means that a change in libegg could break a lot of
> applications.
I think the app authors have been suitably warned :)

> * Most of the things that are used regularly are probably ready to go
> into gtk+ and the gnome libraries.
Which can't really happen til gtk+ 2.4 (some may be able to go into 
gnome 2.2).  These are probably the parts of libegg that are less likely 
to break a lot between releases too, so could probably build against an 
installed static library.

James.

--
Email: james daa com au              | Linux.conf.au 2003 Call for Papers out
WWW:   http://www.daa.com.au/~james/ |   http://conf.linux.org.au/cfp.html