Re: [ros-diffs] [chorns] 19566: Speed up compilation of ntoskrnl

[Alex Ionescu]

Hi,

Do these changes break the MSVC backend?

Best regards,
Alex Ionescu

[Casper Hornstrup]

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(a)reactos.org [mailto:[e-mail]] On Behalf Of Alex
> Ionescu
>  Sent: 25. november 2005 20:23
>  To: ros-dev(a)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(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev

[Alex Ionescu]

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

[Casper Hornstrup]

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(a)reactos.org [mailto:[e-mail]] 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(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev

[Alex Ionescu]

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

[James Tabor]

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

[Steven Edwards]

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/

[James Tabor]

Hi!
Steven Edwards wrote:
>   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
>   
Yes

>   2) It will always be free in terms of cost, where we
> have no promises that MSVC will remain free
>  for our purposes.
>   
Yes

>   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.
>   
Yes, and we need more developers.

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

[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

[Ged Murphy]

Casper Hornstrup wrote:
>     
> >   -----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.
> >
> >      
> >  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.

[Steven Edwards]

Hi,

On 11/26/05, Casper Hornstrup <ch(a)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