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

[Steven Edwards]

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

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

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.

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.

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. 

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



		
__________________________________ 
Yahoo! Music Unlimited 
Access over 1 million songs. Try it free. 
http://music.yahoo.com/unlimited/