Re: [Qemu-devel] [Patch Submission] QEMU with GCC/Win32

[Steve D. Perkins]

Christian MICHON wrote:

> First rule of (efficient) engineering: <<if it is not broken,
> do not try to fix it>>
>
> for the record: gcc-3.3-x is *fine* and *most* stable,
> not just on windows. It's still my reference compiler
> even for linux kernels.
>
> Why do you feel it's necessary to upgrade? Because
> gcc people do? 
>  
   Don't get me wrong, Christian.  I don't advocate using the 
bleeding-edge latest snapshot from CVS as your full-time reference 
compiler.  At the same time, you can't lag behind indefinitely without 
risking irrelevance.  The 3.4.x generation of GCC is several months old 
now (much older if you consider release candidates).  If it's not yet 
time to target 3.4.x as an officially supported compiler, it is AT LEAST 
time to start discussions on a timetable/strategy for doing so. 

   I was unaware that QEMU works properly when built with GCC 3.3.x... 
is that a true statement, or am I reading too deeply into your email?  
If it is true that QEMU builds on Win32 with GCC 3.3 but not 3.4, then 
the "qemu-doc.html" file at the very least should be updated before the 
next release.  That doc simply says "Install the current versions of 
MSYS and MinGW"... which has meant GCC 3.4.x for some time now.

> Now that for the first time on win XP hosts we get
> decent speed, unless patches are really a must, I do
> not intend personnally to upgrade at every snapshot
> my current version of qemu.
>  
   I feel the same way.  I don't plan to upgrade the "production" QEMU 
environment I run my virtual machines in every time there's an 
incremental upgrade.  However, I do plan to build every release for 
testing until the issues we're discussing are resolved, and I'm sure I 
will periodically upgrade my main QEMU environment.

   I don't think that chasing the bleeding-edge is a practical 
approach.  I also don't think that expecting the world to stick with GCC 
3.3 and QEMU 0.6.0 forever is feasible either.  I'm advocating what I 
believe is reasonable middle ground.  This type of discussion is EXACTLY 
why most seasoned open-source projects eventually evolve into "stable" 
and "unstable" branches... so the project can simultaneously meet your 
goal of providing a reliable current release, while providing a 
framework to meet my goal of adapting new things into the project 
incrementally.  Again, I'm just trying to start a discussion.

> In short: there is a team out there. Or this mailing list
> would be dead.
   No offense intended, that was a poor choice of phrasing on my part.  
What I was trying to figure out was whether multiple people are writing 
code for the project, either through direct source-control access or 
sending patches to Fabrice, or if the team's role is more supporting 
Fabrice's coding efforts through QA testing and advice/feedback. 

   Most open-source projects I've been involved with are so STARVED for 
volunteers willing-and-able to actually write code, I was surprised last 
week when I offered to write a patch and the response was dead silence.  
I'm just trying to get a feel for how the project operates, I hope that 
my enthusiasm doesn't come across the wrong way.

Steve