gnash-commit
[Top][All Lists]
Advanced

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

Re: [Gnash-commit] [SCM] Gnash branch, master, updated. release_0_8_9_st


From: Sandro Santilli
Subject: Re: [Gnash-commit] [SCM] Gnash branch, master, updated. release_0_8_9_start-499-gfe94887
Date: Sun, 3 Apr 2011 08:08:14 +0200

On Sun, Apr 03, 2011 at 12:41:34AM -0400, Andrew Guertin wrote:
> On 04/02/2011 07:10 PM, Bastiaan Jacques wrote:
> >commit fe94887b8c648fd3eb4b1030091e5b45a54c15d1 Author: Bastiaan
> >Jacques<address@hidden> Date:   Sun Apr 3 01:05:08 2011 +0200
> >
> >Remove the mudflap targets in subdirectories, because the mudflap target in
> >the toplevel Makefile is quite adequate, and running 'make mudflap' in
> >subdirectories only causes linking problems.
> 
> The top-level target should be removed as well. The correct way to build 
> with mudflap would be to pass the appropriate options to configure in the 
> CXXFLAGS and LDFLAGS. (I actually wrote a patch to remove them all only a 
> few hours before this was checked in.)
> 
> This make target is a minor convenience, but it's not the standard method 
> and as such has deficiencies and problems (off the top of my head: partial 
> rebuilds need to remember to use the same make target, any make targets 
> that build things and are used on their own need special rules (check 
> already has one, but e.g. installcheck doesn't)). Unless the people who use 
> mudflap (not me) say they really want the convenience, the target should be 
> removed in favor of the standard methods.

I never handled to build with mudflap, but next time I try I'd love
to do it the standard way. Could you file a ticked and attach your
patch in there ?

TIA.

--strk; 

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



reply via email to

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