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

[James Tabor]

Hi!
Steven Edwards wrote:
> Hi,
> 
> --- Alex Ionescu <ionucu at videotron.ca> wrote:
> 
>>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.
> 
> 
> I would like to segway for a moment. Support MSVC will greatly incress the exposure of ReactOS to
> the rest of the world. More so than a port to PPC, Sparc, ARM, etc. We must factor that in to how
> we support or do not support it.
> 
> I think we should adopt a policy regarding compiler support like this:
> 
> mingw-gcc is our supported build environment and always will be for the following reasons or rules
> if you will:
> 
> 1) It will always be free as long as we as developers are willing to maintain it even if the mingw
> team disbands
> 
Yes

> 2) It will always be free in terms of cost, where we have no promises that MSVC will remain free
> for our purposes.
> 
Yes

> 3) We gladly welcome developers who want to use MSVC however any patch that breaks the mingw build
> will be rejected. No acceptions. We have to agree on a standard build system to insure stablity
> and lack of regressions. We cannot do this with MSVC and the possiblity of rules 1 and 2.
> 
Yes, and we need more developers.

> 4) We will get SIN/CIS working in such a way that MSVC users will not have to maintain multiple
> build environments to contribute to this project. However rule 3 still applies. If a patch is
> rejected by SIN/CIS it is up to the MSVC developer(s) to figure out a way to make the changes work
> on Mingw before it can go in the trunk.
> 
Yes, or we are smart enough to see what is going on and fix the patch. Let's help first, then reject.

> That being said I think we should adopt a policy of being able to vote out any buildsystem design
> that limits us to just gcc (I did not say mingw). I.E. if we find a change only works on gcc for
> any CPU but totally breaks MSVC or Borland then I think the people that implement that feature
> should at the very least provide a way to make it optional if its a build system change. 
> 
Borland is good too.

> If we are not going to plan on trying to support this sort of design in rbuild there is no point
> in even having the code for multiple backends. We might as well just force people that are working
> on other ports to maintain thier own totally independant build tools.
> 
> Thanks
> Steven
> 
> 
No, we make friends not enemies!


Thanks,
James