Re: [Gnash-dev] Large-scale Makefile.am cleanup

[Rob Savoye]

On 04/19/11 04:12, Andrew Guertin wrote:

> So it looks like you're mainly using it to hack around the normal
> build method to gain speed.

 Speed of development, not speed of an entire build. I've been in this
discussions of recursive vs non-recursive Makefiles several times over
30 years. Each has it's place and it's proponents rarely agree on which
is better. I appreciate your attempt to make Gnash build faster, which
is good, but not at the expense of common development techniques.

> I call this a hack because it's fragile and requires a knowledgeable 
> developer to know when it's permissible and when a full rebuild is 
> required (e.g. in the case of any API/ABI changes), but when it is
> used with caution, it does provide the speed benefit.

  It's not as fragile as you would think. Developers have been using
this trick for decades. When working on new code, like adding a new
renderer, you spend *weeks* adding code primarily in one directory.

> My expectation is that switching to non-recursive would provide
> enough of a speed increase to nearly equal the current hack: the
> major culprits of traversing unchanged directories and linking
> objects multiple times would be removed. Also, even those without the
> ability to determine if the hack is safe (e.g. buildbot) would
> benefit.

  What I would like to see is further tweaks to the hybrid system we use
now. All top level directories would be recursive, and all lower level
convenience libraries would be non-recursive. I think this would keep us
both happy.

> Would you be willing to change your workflow if a switch does speed 
> things up enough?

  Chances are you won't get enough speed improvement to convince me to
change, but I'm open to trying your patches with an open mind. You'd
need a substantial improvement, which I don't think you're going to see.
To speed up linking, I use Binutils Gold, btw.

> (Note that another option is to move to non-recursive, but keep all
> the libraries as-is. This would allow your workflow to remain almost 
> identical. [librender would be a target in the top level (only) 
> makefile, so you would run something like "make libgnashrender.la" 
> instead of "make -C librender".] I don't recommend it, though; better
> is to speed things up enough that hacks aren't necessary.)

  Right, this is the other hack that gets used with non-recursive
Makefiles, which I truly dislike. You need *more* knowledge, or have to
read the Makefile. The other way is faster due to tab completion.

        - rob -