[Pio-temporary] Re: [ pio-Patches-1293678 ] Enable compiler warnings without debugging support

[Bas W. <sh...@fm...>]

> >Comment By: Brian Wellington (bwelling)
> Date: 2005-09-18 20:56
>=20
> Roland - I don't think your patch will work, because the
> specific warnings supported by gcc vary greatly by version
> (and since many distributors shipped patched gcc, even
> version checking isn't enough).

Good point.  However, the warnings are not new: They are currently in
rules.make, and can be enabled with --enable-debug.  I would like to compile
with lots of warnings, but of course it shouldn't break the compilation.  Is
there a solution for this?

> I'm a bit confused as to the intent of the original patch -
> having debugging symbols in a binary doesn't really cause
> any burden other than increased disk usage.  Given that hard
> drives are effectively free (and a pioneers build with
> debugging symbols is still going to use way less space than,
> say, gnome) and debugging symbols are useful if there are
> bugs, I don't know why they should be split.

The difference is more than a factor of 3 for the client (I didn't check the
others).  I don't think it is reasonable to ask people who aren't going to
submit bugs to install that.  At least for Debian they will be stripped
anyway, so that's no problem.  I don't know what other distributions do
though.

I have been building debugging versions of the debian packages, it might be=
 a
good idea to put them on the web somewhere to ask people to use them if we
want more info.  Of course I can only build for my own architecture (althou=
gh
I can provide a package which people can use to build it on their machine),
which is currently i386.

> In my opinion, what should be split is the debug/warning
> code and the deprecation flags.

Sounds good.

> Splitting off -DDEBUG from warnings could also be useful,
> but I don't see any good reason why -DDEBUG and -g should be
> tied together - they're completely unrelated.

The reason they're together (and called --enable-debug) is that you'll want
both when debugging.  I agree though that it makes sense to split them.

> I'd suggest something like:
>   - --enable-gcc-warnings (-Wall, etc)
>   - --enable-debug (-DDEBUG)
>   - --enable-deprecation-checks (or
> --enable-glib-deprecation checks, etc)
>   - possibly a way to set all of these with one flag

Sounds good.

>   - always build with -g unless CFLAGS is set, like most
> other autoconf-based software.

I don't know about this.  Perhaps it makes sense that people who compile fr=
om
source have enough disk space anyway.  Distributions will strip the files
before installing (at least I know I will do that for Debian), so that shou=
ld
be ok.

> I could try to come up with a patch to do this if there's
> interest, but I'm not going to fight with autoconf unless
> there's consensus.

In cases like these, I think it is a good idea to apply a patch which makes
the thing work, and move the report to the feature requests.  While my patch
may not be the final solution, it does fix a problem (it's even more releva=
nt
for the AI-empty-bank-maritime-trade bug).  How about the default policy of
fixing the bug first, and changing the thing later after we decided what's =
the
Right Thing(tm) to do in that situation.  In particular for bugs, it's not
acceptable to leave them open just because we don't know how we want to
restructure the code, IMO.

Thanks,
Bas

--=20
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://129.125.47.90/e-mail.html