Hi,
Do these changes break the MSVC backend?
Best regards, Alex Ionescu
They shouldn't, but I don't build ReactOS with MSVC so I couldn't say for sure.
Casper
-----Original Message----- From: ros-dev-bounces@reactos.org [mailto:ros-dev-bounces@reactos.org] On Behalf Of Alex Ionescu Sent: 25. november 2005 20:23 To: ros-dev@reactos.org Subject: [ros-dev] Re: [ros-diffs] [chorns] 19566: Speed up compilation ofntoskrnl
Hi,
Do these changes break the MSVC backend?
Best regards, Alex Ionescu _______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Casper Hornstrup wrote:
They shouldn't, but I don't build ReactOS with MSVC so I couldn't say for sure.
Casper
I don't want to seem like I'm criticizing you, but I hope that the attitude toward the MSVC backend won't be ' I won't use it so I don't care if I break it"...
Best regards, Alex Ioenescu
I can't fix a problem you have, if you can't tell me how to reproduce it. If you imply that everyone should check their changes for compatibility with MSVC, then I will be strongly against supporting MSVC and any environments other than MinGW because then it's more trouble than it's worth. I will of course assist in finding solutions for any problem that arises due to my contributions, but it is my opinion that support for these environments should be maintained by those who have and use them. The problems that can arise from patches not being compatible with MSVC are new problems. They didn't exist before some developers decided to support MSVC. I would also expect that those who port ReactOS to other architectures and have the hardware will maintain these ports, so that all other developers on the project don't need to verify that their changes work on these architectures. Every time support is added for a new environment or a new architecture the work required maintain ReactOS is increased. It seems only fair that those who want to support a particular feature also do most of the work to support that feature. Most, if not all major projects do it this way and for a good reason - it is the most efficient way.
Casper
-----Original Message----- From: ros-dev-bounces@reactos.org [mailto:ros-dev-bounces@reactos.org] On Behalf Of Alex Ionescu Sent: 26. november 2005 02:06 To: ReactOS Development List Subject: Re: [ros-dev] Re: [ros-diffs] [chorns] 19566: Speed up compilationofntoskrnl
Casper Hornstrup wrote:
They shouldn't, but I don't build ReactOS with MSVC so I couldn't say for sure.
Casper
I don't want to seem like I'm criticizing you, but I hope that the attitude toward the MSVC backend won't be ' I won't use it so I don't care if I break it"...
Best regards, Alex Ioenescu _______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Casper Hornstrup wrote:
I can't fix a problem you have, if you can't tell me how to reproduce it.
No sorry, as I said, my email wasn't specific to you or any problem.
If you imply that everyone should check their changes for compatibility with MSVC,
I believe that's fair.
then I will be strongly against supporting MSVC and any environments other than MinGW because then it's more trouble than it's worth.
So I guess you also think the same about 1) KDBG builds 2) DBG = 0 builds 3) MP builds.
I never added MP or KDBG (Blight did, for the latter), so I should be strongly against supporting it, right?
I will of course assist in finding solutions for any problem that arises due to my contributions, but it is my opinion that support for these environments should be maintained by those who have and use them.
So Blight should maintain KDBG?
The problems that can arise from patches not being compatible with MSVC are new problems. They didn't exist before some developers decided to support MSVC.
MP problems didn't exist before Hartmut/Filip worked on it either..
I would also expect that those who port ReactOS to other architectures and have the hardware will maintain these ports, so that all other developers on the project don't need to verify that their changes work on these architectures.
OK, so I don't need to build an MP build to verifiy my work.. I'll just let Hartmut go through all the trouble?
Every time support is added for a new environment or a new architecture the work required maintain ReactOS is increased. It seems only fair that those who want to support a particular feature also do most of the work to support that feature.
I understand what you mean (ie: if I want to support ReactOS on my toaster, I shouldn't force other devs to support it too), but I hope you realized how my position about KDBG/MP sounded really absurd! They are features used by a non-insignificant portion of users AND they are also a good place to find core bugs. A bug in the MP kernel means its probably there in UP too, are we just going to ignore it? A bug in exception handling might only show up in a feature inside KDBG.
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.
Most, if not all major projects do it this way and for a good reason - it is the most efficient way.
I think it's stupid.
Casper
Best regards, Alex Ionescu
Hi!
Alex Ionescu wrote:
So Blight should maintain KDBG?
Wait now! Unless a developer says, " Hay everyone hold on and don't mess with blaa blaa and blah". That developer may have a vision of something. So if not, it should be open season to touch the code.
Casper
Best regards, Alex Ionescu
Everyone don't make this harder than it should be. Thanks, James
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/
Hi! Steven Edwards wrote:
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:
- It will always be free as long as we as developers are willing to maintain it even if the mingw
team disbands
Yes
- It will always be free in terms of cost, where we have no promises that MSVC will remain free
for our purposes.
Yes
- 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.
- 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
-----Original Message----- From: ros-dev-bounces@reactos.org [mailto:ros-dev-bounces@reactos.org] On Behalf Of Alex Ionescu Sent: 26. november 2005 05:40 To: ReactOS Development List Subject: Re: [ros-dev] Re: [ros-diffs] [chorns] 19566: Speed upcompilationofntoskrnl
Casper Hornstrup wrote:
I will be strongly against supporting MSVC and any environments other than MinGW because then it's more trouble than it's worth.
So I guess you also think the same about
- KDBG builds
- DBG = 0 builds
- MP builds.
I never added MP or KDBG (Blight did, for the latter), so I should be strongly against supporting it, right?
I understand what you mean (ie: if I want to support ReactOS on my toaster, I shouldn't force other devs to support it too), but I hope you realized how my position about KDBG/MP sounded really absurd! They are features used by a non-insignificant portion of users AND they are also a good place to find core bugs. A bug in the MP kernel means its probably there in UP too, are we just going to ignore it? A bug in exception handling might only show up in a feature inside KDBG.
Most, if not all major projects do it this way and for a good reason - it is the most efficient way.
I think it's stupid.
If I wanted to support the Watcom compiler tomorrow, would you verify your changes for compatibility with this compiler? No, I don't think you would want to. So I don't see why it would be stupid to have maintainers (in this case me) make sure ReactOS continues to support a particular environment.
I would be perfectly happy with a rule that said that you should be able to do a successful "mingw32-make depends bootcd" with a particular version of MinGW. Of course we make mistakes that can cause ReactOS to not build correctly, but we can eventually make this problem almost go away with a Continuous Integration System.
We can do a lot to not put added work on these maintainers and have the development process be more smooth. For instance, for the MSVC compatibility feature, the maintainers know the pitfalls. Most MinGW developers do not, and replying to some ros-diff mail for a change that broke MSVC compatibility once in a while, will not make them remember. Maybe they will remember for a little while, but then they will forget it again. Some issues can be avoided by structuring the source code so that the chance of integration problems occurring is less. A recent example is this:
#ifndef __GNUC__ #define DBL_MAX_10_EXP 308 #define S_IFIFO -1 #define UINT64_MAX 0xffffffffffffffff #endif
Here, there is made an assumption about the environment and assumptions lead to integration problems. It is assumed that the environment is either a GNU C compiler (if __GNUC__ is defined) or it is not a GNU C compiler (if __GNUC__ is not defined). It is also assumed, that if __GNUC__ is defined then all three constants are already defined. What the author is trying to accomplish is to make sure that these constants are always defined after the compiler has processed the source code. If the source code was instead written like this:
#ifndef DBL_MAX_10_EXP #define DBL_MAX_10_EXP 308 #endif #ifndef S_IFIFO #define S_IFIFO -1 #endif #ifndef UINT64_MAX #define UINT64_MAX 0xffffffffffffffff #endif
then this source code will not break in a new C compiler environment.
If the pitfalls can't be solved by restructuring the source code so they go away, then they can be documented in wiki. Then there is no need to spend half an hour explaining a committer why his change don't work on MSVC for instance. Just point him to the wiki for an explanation and a solution to the problem.
As for your other examples, there are solutions. For KDBG: Remove this and always build the kernel debugger. Then there is no greater risk of running into integration problems than there is with the rest of the system that is always built.
For MP: Loose most of the hundreds of #ifdef CONFIG_SMP and put most of the source code into their own source code files. Reduce and streamline the interfaces to the functionality in these files.
For DBG: The most common problem is the failure of the compiler to parse the expressions in the assert statements when DBG is defined. Solution: Always parse the expressions even when DBG is not defined.
Casper
Casper Hornstrup wrote:
-----Original Message----- From: ros-dev-bounces@reactos.org [mailto:ros-dev-bounces@reactos.org] On Behalf Of Alex Ionescu Sent: 26. november 2005 05:40 To: ReactOS Development List Subject: Re: [ros-dev] Re: [ros-diffs] [chorns] 19566: Speed upcompilationofntoskrnl
Casper Hornstrup wrote:
I will be strongly against supporting MSVC and any environments other than MinGW because then it's more trouble than it's worth.
So I guess you also think the same about
- KDBG builds
- DBG = 0 builds
- MP builds.
I never added MP or KDBG (Blight did, for the latter), so I should be strongly against supporting it, right?
I understand what you mean (ie: if I want to support ReactOS on my toaster, I shouldn't force other devs to support it too), but I hope you realized how my position about KDBG/MP sounded really absurd! They are features used by a non-insignificant portion of users AND they are also a good place to find core bugs. A bug in the MP kernel means its probably there in UP too, are we just going to ignore it? A bug in exception handling might only show up in a feature inside KDBG.
I think it's stupid.
If I wanted to support the Watcom compiler tomorrow, would you verify your changes for compatibility with this compiler? No, I don't think you would want to. So I don't see why it would be stupid to have maintainers (in this case me) make sure ReactOS continues to support a particular environment.
I think the difference here though, is that one day the msvc compiler may be more popular for building ROS than the mingw compiler. The Watcom compiler will (probably) never be in this situation. Thus I do think it's wise to try and keep full compatability between both mingw and msvc.
As Steven said, the mingw compiler will always need to be the default compiler as it's the only one we know will stay free, but I do think the msvc compiler will surpass it in terms of choice as it's features greatly assist development. Especially as we now support (to some extent) VS 2005, and some devs are making the switch.
I now check all my code on both compilers before submitting. It only takes an extra minute or so.
Hi,
On 11/26/05, Casper Hornstrup ch@csh-consult.dk wrote:
#ifndef __GNUC__ #define DBL_MAX_10_EXP 308 #define S_IFIFO -1 #define UINT64_MAX 0xffffffffffffffff #endif
I will fix this correctly. By the way I am switching email addresses.
-- Steven Edwards - ReactOS and Wine developer
"There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo