RE: [ros-cvs] CVS Update: reactos

[Casper Hornstrup]

Why would we want both variants? 

>   -----Original Message-----
>  From: ros-cvs-bounces(a)reactos.com 
>  [mailto:[e-mail]] On Behalf Of Gregor Anich
>  Sent: 10. december 2004 06:58
>  To: ros-cvs(a)reactos.com
>  Subject: [ros-cvs] CVS Update: reactos
>  
>  CVSROOT:	/CVS/ReactOS
>  Module name:	reactos
>  Repository:	reactos/ntoskrnl/include/
>  Changes by:	blight(a)mok.osexperts.com	04/12/10 06:58:26
>  
>  Modified files:
>  	reactos/ntoskrnl/dbg/: print.c 
>  	reactos/ntoskrnl/include/: config.h 
>  
>  Log message:
>  	Add an option to serialize DbgPrint - don't worry, it's 
>  disabled by default and meant only for those who are tired of 
>  reading mixed debug messages.
>  
>  _______________________________________________
>  Ros-cvs mailing list
>  Ros-cvs(a)reactos.com
>  http://reactos.com/mailman/listinfo/ros-cvs
>

[Ge van Geldorp]

>   From: Casper Hornstrup
>  
>  Why would we want both variants? 
I think we should stay away from this kind of compile-time configuration
options as much as possible. In my opinion, the CONFIG_XXX stuff as found in
the Linux kernel is a big mess and we shouldn't follow their example. When
we basically ship one single set of binaries we have at least a chance to
find bugs which people report, when you have to set a huge number of
CONFIG_XXX constants all bets are off.

Ge van Geldorp.

[Gregor Anich]

Please, look at the options in config.h... It's really meant only for 
developers who are sick of the fucked up debug output. If some user 
decides to play around with these options (the other ones in the 
config.h are things like "strict checking of the nonpaged pool on every 
allocation" or "tracking of statistics about the tagged blocks in the 
pool" and "whole-page allocations") it's really up to the user to fix 
any problems which turn up because of changing these settings.
After all this is a source file, and we don't have something like 
"menuconfig" or just "config" which allows normal users to edit it.

What do you not like about the compile-time configuration? the ifdefs in 
the code or just that it's compile time?

No matter how many options there are, the ReactOS team can always choose 
to ship only a single set of binaries (and support only this set of 
binaries) - everybody who builds ReactOS himself takes the risk of doing 
something wrong.


Ge van Geldorp wrote:

> >  From: Casper
> > Hornstrup
> >
> > Why would we want both variants?
> >     
> >  
> I think we should stay away from this kind of compile-time configuration
> options as much as possible. In my opinion, the CONFIG_XXX stuff as found in
> the Linux kernel is a big mess and we shouldn't follow their example. When
> we basically ship one single set of binaries we have at least a chance to
> find bugs which people report, when you have to set a huge number of
> CONFIG_XXX constants all bets are off.
>
> Ge van Geldorp.
>   
>

[Casper Hornstrup]

>   -----Original Message-----
>  From: ros-dev-bounces(a)reactos.com 
>  [mailto:[e-mail]] On Behalf Of Gregor Anich
>  Sent: 10. december 2004 15:51
>  To: ReactOS Development List
>  Subject: Re: [ros-dev] Compile-time vs. run-time configuration
>  
>  Please, look at the options in config.h... It's really meant 
>  only for developers who are sick of the fucked up debug 
>  output. If some user decides to play around with these 
>  options (the other ones in the config.h are things like 
>  "strict checking of the nonpaged pool on every allocation" or 
>  "tracking of statistics about the tagged blocks in the pool" 
>  and "whole-page allocations") it's really up to the user to 
>  fix any problems which turn up because of changing these settings.
>  After all this is a source file, and we don't have something 
>  like "menuconfig" or just "config" which allows normal users 
>  to edit it. 
Let me refrase my question. Why would anyone want fucked up debug
output?

>   
>  What do you not like about the compile-time configuration? 
>  the ifdefs in the code or just that it's compile time? 
Ifdefs are bad because the compiler skips parts of the sourcecode
like they were comments in certain configurations. This increases
the chance of non-compilable sourcecode getting into CVS. It should
be a goal to have the sourcecode in CVS compilable at all times so we
should develop ReactOS to make this easy for developers. Eventually
I'd like for ReactOS to have only one compile-time configuration - the
target architecture. Other configurations should be in the registry
or handled using another method. After all, that is what the registry
is there for. If there is only one compile-time configuration, the
developer can make sure it still compiles after his change by doing
a full build.

Casper