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

[James Tabor]

Hi!
Steven Edwards wrote:
>   Hi,
>  
>  --- Alex Ionescu <ionucu(a)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