[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnash-dev] Large-scale cleanup

From: Andrew Guertin
Subject: Re: [Gnash-dev] Large-scale cleanup
Date: Wed, 20 Apr 2011 05:05:17 -0400
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9

On 04/19/2011 08:27 AM, Rob Savoye wrote:
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.

Yes, exactly.

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.


   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.

I will write this option up for comparison (when I get to that point).

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

[...] I'm open to trying your patches with an open mind. You'd
need a substantial improvement [...]

Wouldn't expect it any other way :)

Note that the *improvement* will be limited to catching a full "make" up to where "make -C" is at now. I don't think it's possible to make the only-one-library-to-rebuild case go faster: by hand-applying the build rules, you've taken work away from the computer, and it's hard to go any faster than not doing work ;)

(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"
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.

My shell does tab completion for makefile targets :) But point taken.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]