Casper Hornstrup wrote:
I can't fix a problem you have, if you can't tell me how to reproduce it.
No sorry, as I said, my email wasn't specific to you or any problem.
If you imply that everyone should check their changes for compatibility with MSVC,
I believe that's fair.
then I will be strongly against supporting MSVC and any environments other than MinGW because then it's more trouble than it's worth.
So I guess you also think the same about 1) KDBG builds 2) DBG = 0 builds 3) MP builds.
I never added MP or KDBG (Blight did, for the latter), so I should be strongly against supporting it, right?
I will of course assist in finding solutions for any problem that arises due to my contributions, but it is my opinion that support for these environments should be maintained by those who have and use them.
So Blight should maintain KDBG?
The problems that can arise from patches not being compatible with MSVC are new problems. They didn't exist before some developers decided to support MSVC.
MP problems didn't exist before Hartmut/Filip worked on it either..
I would also expect that those who port ReactOS to other architectures and have the hardware will maintain these ports, so that all other developers on the project don't need to verify that their changes work on these architectures.
OK, so I don't need to build an MP build to verifiy my work.. I'll just let Hartmut go through all the trouble?
Every time support is added for a new environment or a new architecture the work required maintain ReactOS is increased. It seems only fair that those who want to support a particular feature also do most of the work to support that feature.
I understand what you mean (ie: if I want to support ReactOS on my toaster, I shouldn't force other devs to support it too), but I hope you realized how my position about KDBG/MP sounded really absurd! They are features used by a non-insignificant portion of users AND they are also a good place to find core bugs. A bug in the MP kernel means its probably there in UP too, are we just going to ignore it? A bug in exception handling might only show up in a feature inside KDBG.
MSVC will be a tool that will be used by a great deal of deverlopers, probably even surpassing mingw in the future in terms of users. I would never say "let's ditch mingw compatibility", but I don't think your argument about msvc stands. The "new problems" that the msvc build introduces are bugs in our code which are simply being exposed. For example, the msvc build is forcing us to stop having crappy headers. And I'm sure the numerous runtime errors it will cause by its fashion of optimizing code will reveal subtle bugs.
Most, if not all major projects do it this way and for a good reason - it is the most efficient way.
I think it's stupid.
Casper
Best regards, Alex Ionescu