Re: glibconfig.h.win32.in: MSVC warning pragmas

[Tor Lillqvist <tml iki fi>]

Hans Breuer writes:

>> It would be OK to have these in config.h.win32.in (and thus only
>> affect compilation of GLib itself). 

> They are as useful for Gtk+, Pango, Gimp, Dia, ...
> so having them only in glib/config.h will IMO defeat the purpose. 

Which all happen to be software from the GNOME CVS repository, that
you happen to be working OK, so it's not a big surprise that you find
them useful... The question is about people working on totally
unrelated software, that uses GLib, or that might use GLib but can't
as their code suddenly doesn't compile any longer because of the
pragmas. Why should GLib force some compiler options upon them? GLib
doesn't force gcc users to use -ansi -pedantic, even if one might as
well say that all software really should use these.

> b) remove those offending #pragma warning(disable:xxxx) but leave
>    the warnings as errors intact

The "warnings as errors" pragmas are quite rude IMHO. Yes, I do know
that for well-written software (like what you, I, and the people on
this list write ;-) these pragmas are only benefical. But should GLib
really force a random developer to start adding lots of casts or
whatever to code that until now has compiled with only a few warnings,
but worked flawlessly, just because he decided to start using GLib's
hash tables, for instance? Wouldn't that be rather obnoxious?

> d) put them into their own header contained in cvs/glib, which gets 
>    included in every glib downstream packages I care for by 'force 
>    include':
>	 -FImsvc_recommended_pragmas.h in every makefile.msc

This seems the most reasonable way to me...

> And if these are not supposed to be in the basic library header
> where do you think they belong ? In any msvc's developers private
> toolbox ?

Umm, yes.

>> The other problem with putting such things in a standard header file
>> is that you are basically frozen at what you picked the first time; if
>> you later change the set or people will suddenly get unexpected
>> results from their compilation.

> As with any other api change. BTW: having them had in glib since
> about two years doesn't count here, does it ? :)

I don't think pragmas for one specific compiler count as API. And if
something was done wrong in the beginning of the GLib porting effort,
that doesn't mean that these mistake have to stay there forever, does
it? (If somebody would have pointed out to me the issues I am now
raising myself, I would certaily had removed those pragmas earlier.)

Besides, I don't really think one can say that GLib on Win32 has been
"stable" or "frozen" API- or otherwise, until now.

--tml