Hi,
--- Alex Ionescu ionucu@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/