xserver autotools questions

Dan Nicholson dbn.lists at gmail.com
Mon May 24 12:56:50 PDT 2010

On Mon, May 24, 2010 at 12:37 PM, Jamey Sharp <jamey at minilop.net> wrote:
> Hi Dan!
> On Mon, May 24, 2010 at 12:01 PM, Dan Nicholson <dbn.lists at gmail.com> wrote:
>> On Sun, May 23, 2010 at 10:34 AM, Jamey Sharp <jamey at minilop.net> wrote:
>>> First, it's been bugging me that a full build of the X server takes so
>>> long, since I keep changing header files that are used everywhere. I
>>> believe switching to non-recursive automake and killing the
>>> intermediate libraries for each subdirectory would help a lot, but
>>> when I tried to test that hypothesis, the mass of configure.ac
>>> declarations defeated me. Can any autotools experts help me out here?
>> I don't see what non-recursive has to do with it. Automake has
>> automatic dependency generation that will cause source files to be
>> recompiled if headers are updated. Non-recursive directories doesn't
>> change that one bit.
> Yes, dependency generation is great, and I wouldn't want to lose it. I
> should have started with the symptoms I was hoping to fix: I can't
> currently saturate the two cores in my laptop, let alone the four in
> the box next to me. I don't think I'm I/O bound, since the whole
> source tree is usually in cache from a build moments earlier. It seems
> like there just isn't enough work available at once.
> I'm building with make -j (doesn't matter whether I use -j6 or just
> -j), ccache, and distcc, and as I see it, the trouble is that there's
> no parallelism across directories.
> There's no way to fix that with recursive make, is there?

No, you're right there. Subdirectories are handled serially. This is
really the one advantage to non-recursive make.

>> The convenience libraries for each subdirectory also don't affect
>> things.
> Time spent in the linker hurts, but if it were parallelized with the
> rest of the build, I suppose it would hurt a lot less. Still, as I
> understand it there's no reason to use the convenience libraries in a
> non-recursive build, and *handwave* it seems like running the linker
> less often should be better.

One of the advantages of convenience libraries is the ability to
modularize the CFLAGS and LIBS more. For instance, since only
libXext.la uses the selinux APIs, you can just link it to -lselinux
and libtool will take care of carrying that linking to the DDX. It's
more convenience than anything.


>> There are reasons to do non-recursive make. However, I don't think
>> this is one of them.
> If I had a good reason to do non-recursive make in the xserver, how
> would you go about getting started? :-)

The automake manual is usually a good place to look for information on
operating automake. :)


>>> Second, I want to factor out code that's shared between two or more
>>> DDXes into a common place. My first target is merging
>>> dmxComputeScreenOrigins with xf86InitOrigins, because I had to make
>>> almost-identical edits to both for a MAXSCREENS removal patch I just
>>> built. Where should that go, and how do I get autotools to link it
>>> correctly?
>> Making a convenience library out of the common source files with
>> noinst_LTLIBRARIES? Of course, that appears to be the part you're
>> trying to avoid above. But the linking is that you just add it to
>> _SOURCES for whatever _PROGRAMS or _LTLIBRARIES it needs to be in.
> It looked like the xserver tree has a much more complicated plan
> going, involving listing every convenience library in variables
> substituted from configure.ac, or something? I'd have copied some
> existing bits if I could figure out what the plan was.

The xserver configuration code as written has some drawbacks, IMO. A
choice was taken to build up the make variables containing references
to all the convenience libraries in configure.ac and then AC_SUBSTing
them. It's not wrong, but I think it would be clearer to build the
stuff in configure.ac that has to be done there and then put the rest
in the Makefile. AC_SUBSTing a variable is the same as just putting it
in the Makefile, though.

I don't know the answer to the common DDX code question, though. :)


More information about the xorg-devel mailing list