Re: [ros-dev] Re: [ros-diffs] [chorns] 19566: Speed up compilationofntoskrnl

[Alex Ionescu]

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