Re: [gtkmm] ANNOUNCE: gtkmm 2.3.3 and glibmm 2.3.4

[nick <nick anvil com>]

Matt et al,
gcc 3.4 is still not a stable release yet and is surely an unsupported
compiler until then. Admittedly it is in a bug fix only state now but
there are some issues that mean it is currently _not_ more C++ compliant
than 3.3 (Template specialisation being one reason ). I suspect when it
finally gets released it will be more conforming to the standard though.

Surely gtkmm should wait until after the compiler is out in a stable
form before any patches are applied. Otherwise we're dealing with a
moving target.  

What's the link to bugzilla that shows your work tracking down the
problem?

Cheers

Nick

On Mon, 2004-02-09 at 14:32, MattyT wrote:
> On Tue, 2004-02-10 at 01:07, Murray Cumming wrote:
> 
> > > Have the GCC 3.4 API fixes gone in yet?
> > What 3.4 fixes? Show me the patches.
> 
> I don't have any patches, the API fixes are not within my realm of
> knowledge.  You know very well I have never contributed anything of
> substance to gtkmm, and as such you should have had no expectation of me
> fixing them.
> 
> I spent days hunting down the causes of the 3.4 problems and gave you
> clear and concise knowledge as to the possible ways to solve these
> problems.  If no one had no time, that's one thing, but as far as I know
> you haven't even tried to get someone to look at them.  I certainly
> haven't seen any messages on the list up to this point.
> 
> I don't know how the gtkmm internals work and don't have time to figure
> it out.  The overloading lookup issues are architectural issues and I
> wouldn't feel competent in making a decision on them for quite a while
> even if I did learn about gtkmm internals.  I wouldn't have a clue what
> else I might be breaking somewhere.
> 
> I already have three projects that I don't have enough time to
> contribute to.  I also have several more that would love to take up my
> time.  I've contributed patches to you before, when I felt qualified to
> do so (for bakery).  When I don't, I'm not going to.  Asking for code
> all the time of anyone who reports an issue isn't going to make it
> magically appear.  The majority of people already know to contribute
> when they can.
> 
> If you want to release buggy software you know how to fix and that you
> know is just going to cause problems with more compliant compilers, that
> might well lead to a flood of useless bug reports and complaints later,
> that's your perogative as project leader.  It's not my place to tell you
> what to do with gtkmm, as you've obviously been quite competent
> technically up to this point.
> 
> But the "show me the code" attitude denigrates the work I put into
> this.  I hunted the problems down, I asked GCC developers about the
> issues, I filed and explained bugs on gtkmm, as well as reporting
> upstream issues to GCC so they don't ever bite gtkmm, which involved
> reducing lots of test cases.  This took a lot of work.  I'd be happy to
> test any fixes.  I've done 90% of the work already on these issues, and
> next time I probably won't bother doing 1%.