non-recursive make (was: [PATCH input-synaptics 2/5] Do not install ChangeLog and README with documentation)

[Dan Nicholson]

On Tue, Jun 14, 2011 at 4:49 PM, Daniel Stone <daniel at fooishbar.org> wrote:
> On Tue, Jun 14, 2011 at 04:02:45PM -0700, Dan Nicholson wrote:
>> On Tue, Jun 14, 2011 at 12:31 PM, Alan Coopersmith
>> <alan.coopersmith at oracle.com> wrote:
>> > xserver on the other hand is huge and could probably be much more parallel
>> > via a non-recursive top-level makefile, but that makefile would be scarily
>> > complex.
>>
>> If you honestly tried to put all the xserver build in a single
>> Makefile, you'd want to stab yourself shortly after. One of the real
>> advantages of recursive make is that skipping parts of the build is
>> really easy. You just put the subdir under an AM_CONDITIONAL and
>> you're done. The actual Makefiles in the subdirectory can stay clean
>> because they're being skipped completely. If you wanted to put that
>> all in a single unit, you'd end up with an insane maze of
>> AM_CONDITIONALs that no one could understand.
>
> In fairness, you can more or less get there via includes, but then you
> have to be mad fascist about trying to keep a load of separate Makefile
> fragments from stepping on each others' toes.

Right, the includes only give you the false impression that the
Makefiles are independent. It might not actually help you at all
because you need to be aware what's going on in 20 other files, too.

>> You know how it's nice when you get rid of #ifdefs in code? This is
>> the opposite of that process.
>
> Heh.
>
> So, something just occurred to me: even worse than the recursion for me
> is the final link into libxorg.a and libxorgtest.a, which seems to be
> caused by per-target flags? On my MacBook Air, all interactivity
> completely dies for about 20 seconds while that link goes on, which
> never used to happen.  So if we could get rid of that, maybe things
> would be a lot quicker.

Sadly, I don't think that's it. Because they're collections of
objects, the archive needs to be rebuilt if anything underneath it
changes. For example, if you change hw/xfree86/common/xf86Xinput.c
(since that's where I've been hanging out :), it causes libcommon.la
to be rebuilt, which then causes libxorg.la to be rebuilt, which then
causes Xorg to be rebuilt. Each one is successively bigger, but each
time libtool has to extract all the objects from the lower .la files
and then link again. I think it's really the convenience libraries of
convenience libraries that make relinking brutal. Run 'make V=1' and
watch the sadness when it gets to libxorg.la.

One thing I'd note is that I don't think libxorg.la is needed at all.
It just collects a bunch of other convenience libraries together. You
could just as easily add them directly to the Xorg link command.
Especially since libtool is just turning around and doing the exact
some process with the exact same objects in Xorg that it just did with
libxorg.la. I started putting a patch together for that, but I'm
getting undefined references on the link. I have to remember how
libtool does things differently when making convenience libraries vs.
programs.

I do see something silly that could be corrected (although I don't
think it would help any here). Xorg.c, libxorg.c and libxservertest.c
are all created as empty files. This is unnecessary if you just
declare an empty _SOURCES. Patch attached for the few times I found
'touch $@' in the source.

--
Dan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: no-empty-sources.patch
Type: application/octet-stream
Size: 3877 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg-devel/attachments/20110614/9944d65a/attachment.obj>