Why would we want both variants?
-----Original Message----- From: ros-cvs-bounces@reactos.com [mailto:ros-cvs-bounces@reactos.com] On Behalf Of Gregor Anich Sent: 10. december 2004 06:58 To: ros-cvs@reactos.com Subject: [ros-cvs] CVS Update: reactos
CVSROOT: /CVS/ReactOS Module name: reactos Repository: reactos/ntoskrnl/include/ Changes by: blight@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@reactos.com http://reactos.com/mailman/listinfo/ros-cvs
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.
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.
-----Original Message----- From: ros-dev-bounces@reactos.com [mailto:ros-dev-bounces@reactos.com] 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