-----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