DRI xorg build

In file included from ../../../GL/glx/glxserver.h:71,
from dri.c:70:
../../../GL/glx/glxscreens.h:47:32: GL/internal/glcore.h: No such file or directory


[Gentoo] X modularizing, day 4

Updated a bunch of stuff today; it was good to see that somebody fixed a bunch of build breakages (Matthieu Herrb, I think). Still a lot of packages doing weird stuff with xprint, using an Xaw m4 macro without stating a dependency upon Xaw among other things.

Adam, here’s a patch for libdrm.pc to make xorg not die when trying to build with DRI.

I also posted a file full of things I’ve got issues with so far in the modularization.

[Gentoo] X modules: Chapter IV. Of curious and conspicuous behavior

I’m just working on the actual server module, xorg. Building with composite seems broken:

i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I../../include -I../../include -I../../include -I../../include -I../../include -I../../include -DHAVE_DIX_CONFIG_H -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -D_XOPEN_SOURCE -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT -I/opt/fdo//include -I/usr/include/freetype2 -I../../include -I../../include -I../../Xext -I../../render -I../../randr -I../../xfixes -I../../damageext -I../../composite -I../../mi -I../../miext/damage
-I../../miext/shadow -I../../fb -I../../Xi -O2 -march=athlon-mp -fomit-frame-pointer -fstack-protector -pipe -MT damage.lo -MD -MP -MF .deps/damage.Tpo -c damage.c -fPIC -DPIC -o .libs/damage.o
damage.c:42:19: cw.h: No such file or directory

Doesn’t include miext/cw, just miext/damage and miext/shadow.

Also I can’t figure out where gl.pc’s supposed to come from — it’s required to build Xdmx with GLX support.

[Gentoo] Modularizing X, chapter III

Just finished up the fonts. I’m thinking of adding a post-dependency in all of them on alias, to make sure it gets merged last. Hope the package manager can handle it.

Now for the important part: the ebuild layout. Here’s the categories I’m looking at so far, which is mostly a mirror of how upstream breaks it down:

  • x11-apps: The various applications that come along.72 ebuilds.
  • x11-proto: The protocol headers. 30 ebuilds.
  • x11-libs: 41 ebuilds.
  • media-fonts: 35 ebuilds.
  • x11-drivers: Haven’t done this yet, but there are 72 directories upstream.
  • x11-base: The actual X server.
  • app-doc: Old-format docs that haven’t been broken into individual packages yet. Probably just a couple ebuilds.
  • x11-misc: The data module, which contains bitmaps and xkbdata. Also the util module, with imake, etc.

My plan is to have a series of “submetabuilds” that combine into a “supermetabuild,” which will be the actual xorg-x11 ebuild. There will be one submetabuild for each major component: apps, drivers, libraries, etc. This will allow me to split USE flags out a bit (so e.g., x11-fonts would have 100dpi, 75dpi, truetype as flags) as well as allow people who only want e.g. libraries for a headless server to get them cleanly.

I’d enjoy hearing thoughts on this.

[Gentoo] Modularizing X ebuilds

Tonight I started work on the modular X ebuilds for 7.0. It went reasonably quickly after I wrote a script to autogenerate tarballs and ebuilds, then install them. I’m still fixing up their dependencies manually, however, so that’s a bit of a slowdown. I made 71 packages — all of the protocol headers and libraries — out of roughly 230 available and autotooled in Xorg CVS.

The main weirdness was module-name overlap between proto/X11 and lib/X11, so I switched the proto one’s name to xproto. I wonder why it isn’t called that in CVS.