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

Anich Gregor blight at blight.eu.org
Sun Nov 28 13:33:24 CET 2004


On Sunday 28 November 2004 11:41, Casper Hornstrup wrote:
> > -----Original Message-----
> > From: ros-dev-bounces at reactos.com
> > [mailto:ros-dev-bounces at reactos.com] 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 ;)



More information about the Ros-dev mailing list