[Xorg] Xevie addition to libXext

[Jim Gettys]

The other problem is that packaging extensions into
a common library is that it means you can't deprecate/withdraw
that extension without breaking applications that use
unrelated extensions.

As history shows (PEX, XIE, to name a few) not all extensions
succeed, and having such unrelated interdependencies are bad
engineering.

And then versioning also becomes interdependent between
libraries, also potentiall causing havoc.

So I'd package them separately.
                        - Jim

On Sun, 2004-08-01 at 18:53, Keith Packard wrote:
> Around 8 o'clock on Aug 1, Stuart Kreitman wrote:
> 
> > just a packaging issue. I was operating under the impression that Xext 
> > was a general purpose place to put small extensions,
> 
> Yes, a tradition started before systems generally had shared libaries 
> though. I think it's a bad plan, although it's probably at least partially
> my fault.
> 
> > We should start a writeup on packaging extensions. Does something like
> > that already exist?
> 
> I think the modular tree has a reasonably clear structure for extensions 
> and I've been following that for the last several I've done:
> 
> 	FooExt/		- headers and specs (no Xlib dependency allowed)
> 	    foo.h	- constants needed by server, library and apps
> 	    fooproto.h	- protocol structures need by server and library
> 	    foo.pc	- pkg-config file
> 	Xfoo/		- C library (including library headers)
> 	    Xfoo.h	- library header
> 	    libXfoo.so	- shared library
> 	    xfoo.pc	- pkg-config file
> 	server/foo	- X server implementation
> 
> One trick is to make sure foo.h and fooproto.h headers don't depend at all
> on Xlib, and to make sure apps needn't use fooproto.h.
> 
> -keith
> 
> 
> 
> ______________________________________________________________________
> _______________________________________________
> xorg mailing list
> xorg at freedesktop.org
> http://freedesktop.org/mailman/listinfo/xorg