Hello,

Looking some examples developing windows drivers using the DDK,
I always noticed the same disposition of the project :

Project
|
|__ src/*.c
[__ inc/*.h

Few times ago I tried to arrange my projects in a different way,
so I try this :

Project
|
|__ src/
| |_ core/*.c
| |_ foo/*.c
| |_ bar/*.c
| |_ mod/*.c
|__ inc/
|_ core/*.h
|_ foo/*.h
|_ bar/*.h
|_ mod/*.h

With this, I had a big problem...I didn't find any way to compile
this solution correctly. I tried different things with Makefile
and sources file but nothing worked.

Do you have any idea to compile this using DDK ?

Regards,

Build a `TARGETTYPE=LIBRARY` for all of the folders with *.c/*.cpp
files, then create a directory with a different target that consumes the
PASS1
by-product of the other folders. Synchronize the whole things
with BUILD_PASS1_PRODUCES/BUILD_PASS1_CONSUMES.

--

--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm


"janemba" <janemba@wanadoo.fr> wrote in message
newsan.2008.01.23.22.41.41.170670@wanadoo.fr...

Hi janemba,

Please follow the steps suggested and read the WDK documentation about
BUILD_CONSUMES/BUILD_PRODUCES (I guess Ivan had these two macros in mind).

The BUILD_CONSUMES macro is used to delay building the specified directory
until the directory containing the corresponding BUILD_PRODUCES macro has
been built.

Note that for the synchronization macros to work, the producer should come
before the consumer in the dirs file; otherwise, build.exe simply ignores the
macros.

It is possible to have a directory being a consumer of more than one
producer; in other words, it can wait on more than one directory to finish
building.

This macro is set in your SOURCES file and is only honored in pass1.

You can have as many BUILD_PRODUCES/BUILD_CONSUMES pair macros in your
sources file.

To consume multiple directories, list one directory per line, with
backslashes between the lines

For example:

BUILD_CONSUMES=\

directoryA \

directoryB \

directoryC \

There is one limitation though:

In Pass1, build.exe only honors the BUILD_CONSUMES macro if the sources file
contains one of the following macros:

NTTARGETFILE1


NTTARGETFILES


LINKLIBS


OBJLIBFILES


PRECOMPILED_OPTIONS


DLLLIBOBJECTS

Build.exe will generate an error if a directory uses any of the Pass1
synchronization macros without defining at least one of these required macros
in the sources file.

The reason for this limitation is that a directory only truly needs
synchronization in pass1 if it contains one of these macros. If the directory
does not contain one of the above macros, build.exe ignores any
synchronization macros for pass1.


Hope this helps,

Tanya



"Ivan Brugiolo [MSFT]" wrote:

"Ivan Brugiolo [MSFT]" wrote:

There are Pass-Specific synchronization macros, and, that's why
I was recomending the _PASSx_ variation of the ones you describe.

--

--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm


"Tanya Radeva {MSFT]" <TanyaRadevaMSFT@discussions.microsoft.com> wrote in
message news:98D79269-CBF9-4801-8C8F-9B4777AA5F6B@microsoft.com...

Isn't DIRS file order enough alone (without BUILD_PRODUCES) to impose a
dependency?

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

Try to build with `dirs` only dependency-order
in a 2-proc quad-core machine a few milions lines of code,
and, you will see the oder dependency go out-of-place, unless explicitely
expressed.
Rember that build.exe is the same tool used to build 50+ milion lines of
codes
hunderds times a day every day, and, there are no guarantees of build-order
simply based upon `dirs` file.
Within the same build pass, everything is equal, unless you express
dependency.
On average, if you have a dual-core / dual-proc machinem and depending
on the trade-off of compile-time/vs-link-time, if you `build /cZ /M:6`
you are in a good place to simulate more concurrency.

--

--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm


"Maxim S. Shatskih" <maxim@storagecraft.com> wrote in message
news:O%23AoC79XIHA.5396@TK2MSFTNGP02.phx.gbl...

Can I rely on DIRS order if I do not use multi-threaded BUILD?

This worked for me for years since NT4 DDK, though I don't remember whether
it was documented.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

"Ivan Brugiolo [MSFT]" <ivanbrug@online.microsoft.com> wrote in message
news:OoPUe9EYIHA.5164@TK2MSFTNGP03.phx.gbl...

Hi Max,

Very good questions!

On a multiprocessor computer we need to control the order of the build so
that the Build utility does not attempt to build a product without first
having built any products on which it depends. This is why
BUILD_PRODUCES/CONSUMES macros came - for synchronization purposes.

But on a uniproc machine I do not see any problem to just use DIRS order.
All subdirectories listed as DIRS arguments are scanned. The doumentation
doesn't say that the DIRS subdirectories are scanned sequentially (although
it is obvious), but I can do further investigation to make this clear.

To help the customer that wants to place his code in src and inc folders I
would suggest the following.

1. Try on a uniproc machine. Use just DIRS order, do not use
BUILD_PRODUCES/CONSUMES for now.
- Create dirs file in Project folder with contents:

DIRS= \
src \

I assume you have subfolders src and inc in your Project folder.

- Create another dirs file in the src subfolder.
DIRS= \
core \
foo \
bar \
mood\

- Create sources file in each subfolder core, foo, bar and mood. When you
specify the INCLUDES, make sure you reference the include subfolders
correctly, for example:
INCLUDES = ..\..\inc\core;..\..\inc\foo, etc...


I am sorry that it takes these additional efforts to organize your Project
code in src and inc folders each with subfolders, etc. It would've been
simpler to have just a sources file in the Project or src folders and specify
the path to the .c or .cpp in the SOURCES macro, but this is not possible.
All files specified by this macro must reside in the directory containing the
sources file or in the parent directory of the sources file.

Hope this helps!

Tanya


"Maxim S. Shatskih" wrote:

By default build.exe uses one process per available CPU.
I seem to rememeber that there is a build.config to override that,
and, there is the `/M` switch on the command line to tune that as well.
These days dual-core machines are commodity, and,
having at least 2 compilers running in parallel is commonplace.
Within the same pass, build.exe does explore
the full set of independent targets and
queues that to worker-process per CPU.

--

--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm


"Maxim S. Shatskih" <maxim@storagecraft.com> wrote in message
news:eQIEgIFYIHA.748@TK2MSFTNGP04.phx.gbl...

Will BUILD default to multi-threaded builds on SMP machine even without command
line options?

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

Yes, Build.exe will defaults to multi-threaded on SMP machine without /M
options or setting BUILD_MULTIPROCESSOR environment variable. Different Build
utility threads may be running on different processors.

"Maxim S. Shatskih" wrote:

On Fri, 25 Jan 2008 16:56:55 -0800, Ivan Brugiolo [MSFT] wrote:


Thanks to all of you