On 8/4/10 6:28 PM, Tiago Vignatti wrote: > Hi Tomas, > > On Tue, Aug 03, 2010 at 10:34:09PM +0200, ext Tomas Carnecky wrote: >> 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). > > I'd like to reinforce that we want a configurable and customizable Xorg, > mostly for who concerns about some constraints such memory footprint. > > So, for instance, mi module may be something that we won't want to build in > some server (think in an Xorg doing and Xvfb role and mi only having rendering > related stuff). Also, RENDER is an extension that right now is mandatory to be > built (28b7b2b8) but some systems may not want to build this (e.g. MeeGo + QT > 4.7 will do everything through GL). I've seen you didn't touch in this aspects > of customization yet but I just want to make sure you have this idea on your > mind.
While I was adding more and more libs into XSERVER_LIBS, I thought about whether all those really are necessary. I don't mean necessary in the sense to make the server usable for modern toolkits (fixes, render etc), but in the sense that they are needed to satisfy the linker. Of course it would be nice to split XSERVER_LIBS into the set of libraries absolutely needed and the set of optional libraries which are linked into each server. However, what you put into XSERVER_LIBS is mostly irrelevant. It's the linker which eventually decides which objects to put into the final binary. Just take a look at mi/miinitext.c: If we're building dmx, undef XV, DBE, XF86VIDMODE etc, now the object file doesn't reference any symbol related to those extensions. For example even though symbols related to Xv are part of libXext.la, and libXext.la is part of XDMX_LIBS, Xv is not linked into the final executable because the symbols are not referenced. > Anyway, I liked the series, Tomas: > Reviewed-by: Tiago Vignatti <tiago.vigna...@nokia.com> > > Maybe you're interesting to vacuum up a patch I sent some weeks ago > (eventually applying Dan's comments): > http://lists.x.org/archives/xorg-devel/2010-July/010697.html libdix.la is already part of libxorg.la, so if anything that was part of libdix.la was changed libxorg.la should have been rebuilt. libmain.la missing from the dependencies was a genuine bug, but with my changes it's not needed anymore, libxorg.la now includes all in-tree libraries which make up Xorg, including libmain.la. tom _______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel