[RFC] configure/makefile cleanup

Tomas Carnecky tom at dbservice.com
Tue Aug 3 13:34:09 PDT 2010


The gloal of this patchset is to simplify the configure.ac script and
the makefiles, especially the definitions of variables which hold the
set of libraries linked to each server.

There are libraries which each server has to link to, those include
the core implementation of the server (libdix.la, libos.la, libmi.la)
plus any extensions which are either required by the DIX (XFixes) or
always enabled (XKB, Damage, Render, Randr, XInput). And then there
are out-of-tree libraries (system libraries) which are required by
all servers. Each server may also link with optional in-tree and
out-of-tree libraries (for example extensions which depend on
support in the DDX which is only provided by that particular server).

Each server defines two autoconf variables in the configure
script: FOO_LIBS and FOO_SYS_LIBS. Previously each server would
manually fill those with the required and optional libraries.
After this patchset FOO_LIBS is defined as XSERVER_LIBS plus any
of the server-specific in-tree libraries. FOO_SYS_LIBS as
XSERVER_SYS_LIBS plus any server-specific out-of-tree libraries.

So each server makefile can now simply add FOO_LIBS, FOO_SYS_LIBS plus
any server-specific in-tree libraries (those compiled from sources in
hw/foo/*) to the server _LDADD rule.

Especially difficult was to figure out which extensions depend on what,
as you see in patch 3, OS_LIB depends on FIXES_LIB (EnabledCursor).
Then also RENDER_LIB depends on OS_LIB (x_sha1_* methods) and there
may be other dependencies which I'm not aware of. I'd like to see
a list or document or even just a header which describes what each
extension expects and relies on. I can do that for DPMS (now that I've
spent so much time going through that code), but that extension is
pretty simple when it comes to dependencies. In fact, I've dedicated
one of the headers to just define what each extension expects and/or
uses from the DDX/DIX. RFC code will follow shortly.. 

tom



More information about the xorg-devel mailing list