RE: [ros-dev] Re: [ros-diffs] [chorns] 19566: Speed upcompilationofntoskrnl

[Casper Hornstrup]

>   -----Original Message-----
>  From: ros-dev-bounces(a)reactos.org [mailto:[e-mail]] 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
>  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 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