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

[Sandro Santilli]

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.
https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/673893

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

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

--strk;

  ()   Free GIS & Flash consultant/developer
  /\   http://strk.keybit.net/services.html