Re: [ros-dev] Moving ntoskrnl configuration defines into ntoskrnl/include/config.h ?

[Anich Gregor]

On Sunday 28 November 2004 11:41, Casper Hornstrup wrote:
> >   -----Original
> > Message-----
> >  From: ros-dev-bounces(a)reactos.com
> >  [mailto:[e-mail]] On Behalf Of Gregor Anich
> >  Sent: 28. november 2004 00:51
> >  To: ReactOS Development List
> >  Subject: [ros-dev] Moving ntoskrnl configuration defines into
> >  ntoskrnl/include/config.h ?
> >
> >  Hi!
> >
> >  I would like to add the possibility of configuring things
> >  like WHOLE_PAGE_ALLOCATIONS or TAG_STATISTICS_TRACKING (from
> >  ntoskrnl/mm/npool.c) It would be good if such defines were
> >  moved into a file like ntoskrnl/include/config.h which is
> >  then included by ntoskrnl.h and looks like this:
> >
> >  /* Enable tracking of statistics about the tagged blocks in
> >  the pool */ #undef TAG_STATISTICS_TRACKING
> >
> >  /*
> >   * Put each block in its own range of pages and position the
> >  block at the
> >   * end of the range so any accesses beyond the end of block
> >  are to invalid
> >   * memory locations.
> >   */
> >  #undef WHOLE_PAGE_ALLOCATIONS
> >
> >  I don't want to make the tool edit the C files directly. 
>  WHOLE_PAGE_ALLOCATIONS shouldn't be a compile time define. The
>  code should be written to retrieve the setting from registry
>  instead. The reason is to minimize the number of compile time
>  defines in the code base. The more compile time defines there
>  is, the harder it is to make sure a particular change does
>  not break building with one or more of the configurations.
>  Ususually a developer does not want to do a make clean &
>  reconfigure & make for each configuration to make sure it does
>  still build in those configurations. The same goes for KDBG.
>
>  Casper
>  
Hi!

It would be cool if our build system supported to select the target directory 
so one can use one source directory, 2 configurations and build each 
configuration into a different target directory ;-)

But that wouldn't solve the problem you described either, it would just reduce 
diskspace requirements if one wants to have a dbg and non-dbg build for 
example (to test building of both before commiting stuff for example)

€0.02 - blight ;)