Actually, build.exe supports parallel build and also quite scalable to large projects.
build.exe -M option specifies how many processors the build may use. Build.exe creates a child process for nmake.exe as many as specified/possible. Header and library dependencies are automatically checked in most cases (?). It also provides BUILD_{CONSUMES|PRODUCTES}, SYNCHRONIZE_{BLOCK|DRAIN} macros as synchronization primitives. See topics in “Building on a Multiprocessor Computer” in DDK help if you are interested.
As for other non traditional outputs (.exe or .sys), you can always directs to include your makefile.inc by specifying NTTARGETFILE{0,1,S} in SOURCES.
Another helpful hint is “project.mk”. In parent directories in your source tree, if “project.mk” is found, it is automatically included by makefile.def (defined in makefile.plt). You can define your project-wide nmake macros there such as library directories, common header directories, etc.
But lots of features are still undocumented and I hope that Microsoft provides more documentation, such as user-mode WPP, SIGNCODE_CMD, SXS, etc.
Regards,
Chesong Lee
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of bank kus
Sent: Wednesday, August 30, 2006 4:51 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] trouble with SOURCES
“Martin O’Brien” wrote in message
news:xxxxx@ntdev…
> JEREMY:
>
> As far as SOURCES/DIRS/BUILD goes, no you’ve got it right - it really,
> really sucks. To do what you wish you have three basic options:
>
> 1. The one you have already described
> 2. Include the .C/.CPP files from the folder in which you compile
> 3. Don’t use BUILD
>
> Personally, I think that people who chose (2) are insane, as it breaks
> basically every fundamental rule and/or convention governing separate
> compilation, and still results in a far from transparent hack to
> workaround around a build system.
>
> I’ve used something I’ve written (just a set of makefiles and a couple
> of perl scripts) for about seven years. As long as you check that the
> compiler and linker settings are still valid with each new DDK/WDK that
> you use, you shouldn’t have any trouble. The only nice feature of BUILD
> that gets lost here (assuming you use only CL, LINK, and NMAKE) is
> automatic dependency information.
Cant agree any more with it. GNU Make ( and its Windows port Mingw ) works
for me but it has its own restrictions.
Particularly the topic of recursive build can be a hairy one that modern
build systems
like Makepp/ JAM do better at. The topic of contention being do you
createprocess (make.exe or whatever your tool is )
once for each directory or do you include your sub directory Makefiles into
the parent makefile and run Make just once.
Apart from the createprocess overhead, continous directory recursion is bad
for build level parallelism.
I think in one of the replies somebody from Microsoft mentioned parallel
builds. I was not aware whether build.exe / nmake
is capable of parallel build / dependency tree walking capability. Or is it?
Anyways, I think build.exe is a good tool for small scale drivers and for
getting started project. But as the size of your driver increase
and you start having auto code/header/ Makefile generation, you ll need to
pull back with a traditional build system.
> I can’t help you with your second question (WPP), as I know nothing
> about it. I looked at it once, and decided that KdPrint was just fine.
>
> Good luck,
>
> MM
>
>
>
>>>> xxxxx@telestream.net 2006-08-28 17:56:02 >>>
> I would like to organize my driver source code into subdirectories
> based
> on the codes primary function and I’m having a lot of trouble. I’ve
> read
> through OSR Online, Google, and the DDK Docs and I’ve found that the
> only good way to do this is to make each subfolder a library, and then
>
> link them all together. First, I just want to say that I think this
> sucks. It is frustrating enough that I have to jump through so many
> hoops to just use basic C++, and then to add insult to injury, I can’t
>
> even organize my source files in an object oriented way. Has everyone
> just gotten used to the ridiculous restrictions in SOURCES files, or am
>
> I just missing out on some import concept?
>
> Anyway, enough ranting. My new problem is trying to include *.tmh files
>
> in my library. I tried adding the RUN_WPP code to my libraries SOURCES
>
> file, but nothing was generated. Should I try to include the *.tmh file
>
> from my parent project? How do I add the correct include path to my
> libraries SOURCES file?
>
> Thanks,
> --Jeremy
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
—
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
