[Xcb] Re: XCB library structure

[Bart Massey]

I see only three sensible alternatives for structuring XCB +
extensions.  If there are others, please tell me.  Here they
are, in order of decreasing bart-preference:

1) Just have libXCB include everything, including all
   implemented extensions.
2) Have libXCB include "common extensions", and have a
   libXCBfoo library for each extension foo that we expect
   to be "rarely used".
3) Have libXCB be just the core, and have each extension foo
   have its own libXCBfoo library.

IMHO, we should ship (1) as the standard build, but always
be able to build (3).  This will allow customizers to build
a specific version of (2) if they so desire, and ensure that
new extensions can be compiled seperately in a sensible way
until they are integrated into (1).

Does this make sense?

(I think you did misunderstand my question: I'm just asking,
whether anyone can imagine a situation in which a few 10s of
KB of extensions bloats the core beyond usefulness.  Seems
unlikely IMHO.)

"Useful" != "demo apps" :-), but it *is* amazing how well
the core protocol has held up, with the exception of the
rendering primitives and a few rough edges.

	Bart

In message <20031030085835.GN813@sharp.ath.cx> you wrote:
> 
> --===============0515421221==
> Content-Type: multipart/signed; micalg=pgp-sha1;
> 	protocol="application/pgp-signature"; boundary="9uDGw67+9J53IzxX"
> Content-Disposition: inline
> 
> 
> --9uDGw67+9J53IzxX
> 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).
> >=20
> > 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
> protocol.
> 
> 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!)
> --=20
> Jamey Sharp <jamey@minilop.net> - http://minilop.net/
> 
> --9uDGw67+9J53IzxX
> Content-Type: application/pgp-signature
> Content-Disposition: inline
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.3 (GNU/Linux)
> 
> iD8DBQE/oNK7NgAXSpyH6VcRAhAhAJ9KfqIi77BLwiHFuMZFijBcxrDspQCfTDLY
> Glg/KXi2nlGfdhraQOW+DR0=
> =taiU
> -----END PGP SIGNATURE-----
> 
> --9uDGw67+9J53IzxX--
> 
> 
> --===============0515421221==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
> 
> _______________________________________________
> XCB mailing list
> XCB@xcb.wiki.cs.pdx.edu
> http://nexp.cs.pdx.edu/cgi-bin/mailman/listinfo/xcb
> 
> --===============0515421221==--
>