[Xcb] XCB structure

Jamey Sharp jamey@cs.pdx.edu
Thu, 30 Oct 2003 00:58:35 -0800

Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 10/29 10:28PM, Bart Massey wrote:
> In message <20031030014906.GL813@sharp.ath.cx> you wrote:
> > XCB now generates two libraries: libXCB, with the core protocol
> > only, and libXCBext, which currently has the SHAPE, SHM, RENDER, and
> > DPMS extensions (because that's exactly the set of extensions that
> > anyone has implemented yet).
> I thought the plan was to have one library per extension, and use
> library dependency magic to ensure that the extension libraries
> brought in the core?  Or am I confused?

I didn't recall that being the plan, but it seems like a fine plan. I
thought the plan was to include the most common things in a single
library to avoid long lists of -l flags for applications using a bunch
of common extensions, but I don't think there are a bunch of common
extensions, so one per library sounds just fine.

I did it this way as a proof of concept more than anything else, and I
haven't tested the dependency magic with this code yet. It's easy to do
as many libs as desired with automake.

Statistics: I thought libXCB was running 35kB with the core only, but it
turns out I only forgot to compile with -O2. It's 24.89kB, and libXCBext
is 11.8kB, when you measure the text sections of the static libs.

> In any case, is there any reason to have just the core without
> extensions?

I must assume I don't understand the question, because I thought the
answer was obviously "yes". The core still includes the entire core

Cool note: Most of the existing XCB demo apps do interesting things
without using any extensions, illustrating that there are still useful
things to be done with only the core protocol devised more than a decade
ago. (Go X!)
Jamey Sharp <jamey@minilop.net> - http://minilop.net/

Content-Type: application/pgp-signature
Content-Disposition: inline

Version: GnuPG v1.2.3 (GNU/Linux)