gnash-dev
[Top][All Lists]
Advanced

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

Re: [Gnash-dev] [patch] Fix linker problem with current CVS, and enable


From: Rob Savoye
Subject: Re: [Gnash-dev] [patch] Fix linker problem with current CVS, and enable more warnings
Date: Wed, 29 Mar 2006 10:09:22 -0700
User-agent: Thunderbird 1.5 (X11/20051201)

Petter Reinholdtsen wrote:

Well, as a debian maitainer, one of the first things I do when I
consider maintaining a package, is to see how much warnings are
produced by the compiler when lots of warnings are enabled, and if it
is a lot I normally postpone maintaining the package until the code
quality improves.  And besides, a lot of the warnings from gcc are

Many of the warnings pre-date Gnash, and are the result of some mighty ugly and ancient C++ code. I prefer to have all my projects build without any warnings, but for Gnash to do that, it would need somebody to spend the time to go through these and fix them. Some have been fixed already, but there are a pile left to go through...

includes getting it to build with -ansi if you want the code to build
on Irix and HP-UX. :)

Right, but I don't know if I can about HPUX anymore. :-) (I spent years as a developer on HP-UX...) And Irix drives me nuts... Joking aside, I guess it would be nice if Gnash could run on these Unix variants, as well as Solaris.

Anyway, if you do not want to enable all these warnings by default,
what about making it a configure option?  Something like this should
do the trick.

Ah, that'll work. I just added this, it'll get checked in later. Ideally somebody will use this configure options and start cleaning up all the warnings.

later!".  It is fixed now.  the SWF file is available from
<URL:http://www.boinydalen.no/solsiden.swf>.

  It plays fine for me using the standalone player. :-) (ia32-ubuntu)

But do not add the build rules to CVS or at least not in the released
tarball without talking to the prospective maintainer (Miriam Ruiz, I
guess from reading the debian bug report), as some maintainers prefer
to keep the upstream tarball and the debian build rules completly
separate to ease debian package maintainence.

I usually maintain both rpm and Debian packaging files, as I like to build debs and rpms when I make a release as not everybody grabs a package from the distribution. Especially when I start doing snapshots. But I usually don't put the packaging directory in the release, it just lives in CVS for my own purposes.

Miriam made a bunch of earlier suggestions I had to change so packaging worked better. Those suggestions were all incorporated.

        - rob -




reply via email to

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