26 Nov
2005
26 Nov
'05
6:13 a.m.
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
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/