[Xorg] Xevie addition to libXext
Jim.Gettys at hp.com
Sun Aug 1 17:31:31 PDT 2004
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
As history shows (PEX, XIE, to name a few) not all extensions
succeed, and having such unrelated interdependencies are bad
And then versioning also becomes interdependent between
libraries, also potentiall causing havoc.
So I'd package them separately.
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.
> xorg mailing list
> xorg at freedesktop.org
More information about the xorg