[Top][All Lists]
[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 -