[Top][All Lists]

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

Re: [Gnash-dev] Large-scale cleanup

From: Sandro Santilli
Subject: Re: [Gnash-dev] Large-scale cleanup
Date: Tue, 19 Apr 2011 14:52:12 +0200

On Tue, Apr 19, 2011 at 06:27:37AM -0600, Rob Savoye wrote:

>   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'd be happy with merging libcore/asobj and libcore/vm into libcore, 
for a start.

> To speed up linking, I use Binutils Gold, btw.

Just a note: Ubuntu 10.04 (LTS) shipped a gold incompatible with libc.
I've had an hard morning trying to debug random segfaults the other day.

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

Oh, since we're talking about it, I moved dump gnash in its own dir,
where you don't have utility libs, and specifically to speedup
rebuilds during developmeng of that specific client, and saw it moved
back to recursive in the hwaccel branch.
Should we move to recursive GUI/ subdirs instead ?
After all each executable is linked separately...


  ()   Free GIS & Flash consultant/developer

reply via email to

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