How to use SOURCES to compile on diferent paths.

NTDEV
1

Hi all,

I’m trying to compile a static library which is composed by source files
in different paths.

DIR_ONE
makefile.def
sources
File1.c
File2.c

DIR_TWO
File3.c
File4.c

I was trying to use SOURCES as follow.

SOURCES=\
File1.c \
File2.c \
…\DIR_TWO\File3.c \
…\DIR_TWO\File4.c

But it doesn’t works.
So I’m trying to use the macro SOURCES_USED, but DDK documentation is
not so clear for me.

Can anyone help?

Thanks in advance.
Fernando Roberto da Silva.

2

Search the archives, been answered a million times:

http://www.osronline.com/showThread.cfm?link=25134
http://www.osronline.com/showThread.cfm?link=77650
http://www.osronline.com/showThread.cfm?link=13217

(I’ll leave finding the other 999,997 threads on the topic as an exercise
for the OP)

-scott

–
Scott Noone
Software Engineer
OSR Open Systems Resources, Inc.
http://www.osronline.com

“Fernando Roberto” wrote in message
news:xxxxx@ntdev…
Hi all,

I’m trying to compile a static library which is composed by source files in
different paths.

DIR_ONE
makefile.def
sources
File1.c
File2.c

DIR_TWO
File3.c
File4.c

I was trying to use SOURCES as follow.

SOURCES=<br> File1.c <br> File2.c <br> …\DIR_TWO\File3.c <br> …\DIR_TWO\File4.c

But it doesn’t works.
So I’m trying to use the macro SOURCES_USED, but DDK documentation is not so
clear for me.

Can anyone help?

Thanks in advance.
Fernando Roberto da Silva.

3

This has been discussed many times on the list before. BUILD only
supports source files in the current directory. Basically, you have 2
choices. You can make file3 and file4 into a library and link against
it. Or, you can have a one-line ‘dummy’ file in the current directory
which #includes the file you are really interested in (ie, "#include
“…\dir_two\file3.c”).

Search the archives for further details.

ScottR

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Fernando Roberto
Sent: Tuesday, June 20, 2006 10:28 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] How to use SOURCES to compile on diferent
paths.

Hi all,

I’m trying to compile a static library which is composed by
source files in different paths.

DIR_ONE
makefile.def
sources
File1.c
File2.c

DIR_TWO
File3.c
File4.c

I was trying to use SOURCES as follow.

SOURCES=\
File1.c \
File2.c \
…\DIR_TWO\File3.c \
…\DIR_TWO\File4.c

But it doesn’t works.
So I’m trying to use the macro SOURCES_USED, but DDK
documentation is not so clear for me.

Can anyone help?

Thanks in advance.
Fernando Roberto da Silva.

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

4

I’m thinking that the frequency with which this question is asked should
give MS a hint that the limitations of build are a problem. The build
utiltiy shouldn’t be forcing a directory structure on developers the way
it is. Different projects require different directory structures. That
structure should be up to the designer of the project to determine, not
the build utility.

(Sorry, couldn’t resist the urge to rant about this one more time)

Beverly

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Robins, Scott
Sent: Tuesday, June 20, 2006 10:44 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] How to use SOURCES to compile on diferent paths.

This has been discussed many times on the list before. BUILD only
supports source files in the current directory. Basically, you have 2
choices. You can make file3 and file4 into a library and link against
it. Or, you can have a one-line ‘dummy’ file in the current directory
which #includes the file you are really interested in (ie, "#include
“…\dir_two\file3.c”).

Search the archives for further details.

ScottR

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Fernando Roberto
Sent: Tuesday, June 20, 2006 10:28 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] How to use SOURCES to compile on diferent
paths.

Hi all,

I’m trying to compile a static library which is composed by
source files in different paths.

DIR_ONE
makefile.def
sources
File1.c
File2.c

DIR_TWO
File3.c
File4.c

I was trying to use SOURCES as follow.

SOURCES=\
File1.c \
File2.c \
…\DIR_TWO\File3.c \
…\DIR_TWO\File4.c

But it doesn’t works.
So I’m trying to use the macro SOURCES_USED, but DDK
documentation is not so clear for me.

Can anyone help?

Thanks in advance.
Fernando Roberto da Silva.

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

5

Best of luck, Doña Quixote…

Brown, Beverly wrote:

I’m thinking that the frequency with which this question is asked should
give MS a hint that the limitations of build are a problem. The build
utiltiy shouldn’t be forcing a directory structure on developers the way
it is. Different projects require different directory structures. That
structure should be up to the designer of the project to determine, not
the build utility.

(Sorry, couldn’t resist the urge to rant about this one more time)

Beverly

*From:* xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] *On Behalf Of *Robins, Scott
*Sent:* Tuesday, June 20, 2006 10:44 AM
*To:* Windows System Software Devs Interest List
*Subject:* RE: [ntdev] How to use SOURCES to compile on diferent paths.

This has been discussed many times on the list before. BUILD only
supports source files in the current directory. Basically, you have 2
choices. You can make file3 and file4 into a library and link against
it. Or, you can have a one-line ‘dummy’ file in the current directory
which #includes the file you are really interested in (ie, "#include
“…\dir_two\file3.c”).

Search the archives for further details.

ScottR

-----Original Message-----
*From:* xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] *On Behalf Of *Fernando
Roberto
*Sent:* Tuesday, June 20, 2006 10:28 AM
*To:* Windows System Software Devs Interest List
*Subject:* [ntdev] How to use SOURCES to compile on diferent paths.

Hi all,

I’m trying to compile a static library which is composed by source
files in different paths.

DIR_ONE

makefile.def

sources

File1.c

File2.c

DIR_TWO

File3.c

File4.c

I was trying to use SOURCES as follow.

SOURCES=\

File1.c \

File2.c \

…\DIR_TWO\File3.c \

…\DIR_TWO\File4.c

But it doesn’t works.

So I’m trying to use the macro SOURCES_USED, but DDK documentation
is not so clear for me.

Can anyone help?

Thanks in advance.

Fernando Roberto da Silva.

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

–
Ray

6

This is why I always describe the 'solutions' instead of just pointing
the previous discussions. The 'solutions' are so ridiculous that any
reasonably astute programmer (hell, anyone past CS 101) will see them as
hacks and realize that build is flawed.

ScottR
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Tuesday, June 20, 2006 2:17 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] How to use SOURCES to compile on diferent
paths.

I'm thinking that the frequency with which this question is
asked should give MS a hint that the limitations of build are a problem.
The build utiltiy shouldn't be forcing a directory structure on
developers the way it is. Different projects require different directory
structures. That structure should be up to the designer of the project
to determine, not the build utility.

(Sorry, couldn't resist the urge to rant about this one more
time)

Beverly

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Robins, Scott
Sent: Tuesday, June 20, 2006 10:44 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] How to use SOURCES to compile on diferent
paths.

This has been discussed many times on the list before. BUILD
only supports source files in the current directory. Basically, you
have 2 choices. You can make file3 and file4 into a library and link
against it. Or, you can have a one-line 'dummy' file in the current
directory which #includes the file you are really interested in (ie,
"#include "..\dir_two\file3.c").

Search the archives for further details.

ScottR

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Fernando Roberto
Sent: Tuesday, June 20, 2006 10:28 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] How to use SOURCES to compile on
diferent paths.

Hi all,

I'm trying to compile a static library which is composed
by source files in different paths.

DIR_ONE
makefile.def
sources
File1.c
File2.c

DIR_TWO
File3.c
File4.c

I was trying to use SOURCES as follow.

SOURCES=\
File1.c \
File2.c \
..\DIR_TWO\File3.c \
..\DIR_TWO\File4.c

But it doesn't works.
So I'm trying to use the macro SOURCES_USED, but DDK
documentation is not so clear for me.

Can anyone help?

Thanks in advance.
Fernando Roberto da Silva.

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 ListServer/Forum

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
ListServer/Forum

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

7

For the umpteen millionth time: Microsoft didn’t create build for the benefit of the driver development community. It just happens to be the utility that’s used to build the entire Windows operating system, including all user-mode and kernel-mode components.

So, tilt at windmills all you like… just don’t complain at the result of your efforts.

Peter
OSR

8

Maybe they didn’t design it for us to use, but they distribute it for us
to use and it doesn’t suit our needs in many instances. Our needs !=
their needs.

All I am saying is that the tool may need an update in order to meet the
needs of the developers.

Beverly

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
Sent: Tuesday, June 20, 2006 3:13 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] How to use SOURCES to compile on diferent paths.

For the umpteen millionth time: Microsoft didn’t create build for the
benefit of the driver development community. It just happens to be the
utility that’s used to build the entire Windows operating system,
including all user-mode and kernel-mode components.

So, tilt at windmills all you like… just don’t complain at the result
of your efforts.

Peter
OSR

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

9

xxxxx@osr.com wrote:

Microsoft didn't create build for the benefit of the driver development community.

This truth we hold self-evident.

So, tilt at windmills all you like... just don't complain at the result of your efforts.

If the windmills weren't rearing up, breathing fire, and terrorizing our
build environments at the whim of their evil master in Redmond we might
not care :-).

Translating that from the original Spanish: Microsoft lost the right to
use the excuse that build.exe was an internal tool the moment that they
decided to require that it be used by everyone. That's even formal now,
given the Prefast requirements for Vista WHQL.

I use the shim trick too, but that has its own severe annoyance: build
doesn't detect that dependency properly, so you have to touch your shim
in order to get it to rebuild your changed source file (unless there's
some trick I haven't found yet... Hmmm, I haven't tried making my shims
.h files included by a separate shim .cpp file... but on the other hand
I just ate).

Ray

10

All files mentioned in SOURCES must be in the same directory, sorry. Maybe
“…” is working, but nothing else.

Build 2 static libraries if you need to bypass this.

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

----- Original Message -----
From: “Fernando Roberto”
To: “Windows System Software Devs Interest List”
Sent: Tuesday, June 20, 2006 6:28 PM
Subject: [ntdev] How to use SOURCES to compile on diferent paths.

Hi all,

I’m trying to compile a static library which is composed by source files
in different paths.

DIR_ONE
makefile.def
sources
File1.c
File2.c

DIR_TWO
File3.c
File4.c

I was trying to use SOURCES as follow.

SOURCES=<br> File1.c <br> File2.c <br> …\DIR_TWO\File3.c <br> …\DIR_TWO\File4.c

But it doesn’t works.
So I’m trying to use the macro SOURCES_USED, but DDK documentation is
not so clear for me.

Can anyone help?

Thanks in advance.
Fernando Roberto da Silva.

—
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

11

Another trick I have used when faced with similar situations (like an
existing cross-platform source tree that suddenly has to include a
driver for Windows) is to use the JUNCTION.EXE tool from SysInternals
(http://www.sysinternals.com/utilities/junction.html).

When I’ve used it, I normally create a subdirectory (or a parallel
directory tree) for building the Windows component(s) which is laid out
in a way that BUILD will handle, linking to the appropriate files in the
existing source tree. This is not ideal, and imposes constraints on the
build environment, but it has proved to be an enormous time-saver in
certain situations.

Do read the KB article referred to on the SysInternals page, and most of
all remember that reparse/junction points do not behave entirely like
*nix links.

Cheers,

– mkj

//
// Michael K. Jones
// Stone Hill Consulting, LLC
// http://www.stonehill.com
//_______________________________________________

12

If you say so. My point is, the driver development community is not the primary consumer of this utility, nor is its use in building drivers a “design center” for the tool. In fact, the use of build in the DDK is a coincidental use of the tool, at best.

Build was originally designed by Steve Wood (now THERE’s a name you don’t hear every day) back in 1989 as the tool that was used to build Windows NT. To this day, they use it to build Windows (and a bunch of other products as well) every day. They designed it, and they apparently like it the way it works.

I guess that’s not a reason to stop raising issues with the tool. I’m just trying to help set the expectations of community members about the chances of success.

Peter
OSR

13

Most of us (at least those who have been developing drivers for a while)
understand the history of the tool. However, history aside, it is now a
required tool for driver development. As such, it may be time for a
redesign in order to take into account its current use.

Beverly

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
Sent: Wednesday, June 21, 2006 12:50 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] How to use SOURCES to compile on diferent paths.

If you say so. My point is, the driver development community is not the
primary consumer of this utility, nor is its use in building drivers a
“design center” for the tool. In fact, the use of build in the DDK is a
coincidental use of the tool, at best.

Build was originally designed by Steve Wood (now THERE’s a name you
don’t hear every day) back in 1989 as the tool that was used to build
Windows NT. To this day, they use it to build Windows (and a bunch of
other products as well) every day. They designed it, and they
apparently like it the way it works.

I guess that’s not a reason to stop raising issues with the tool. I’m
just trying to help set the expectations of community members about the
chances of success.

Peter
OSR

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

14

I see both sides of this issue, probably because I do not use BUILD (I
hate pretty much everything about it). On the one hand, personally, I
would not want to have to make the argument that BUILD is optional,
until, minimally, (1) Microsoft documents the compiler and linker
switches required/recommended to build drivers (as well as stop using
undocumented one); and (2) the preamble about only BUILD should be used
to build drivers is removed the documentation. The history aside, it’s
kind of ridiculous. On the other, it is free, used for other purposes,
and there is not a lot of incentive for Microsoft to spend the resources
to change it.

MM

>> bbrown@mc.com 2006-06-21 12:59:54 >>>
Most of us (at least those who have been developing drivers for a
while)
understand the history of the tool. However, history aside, it is now
a
required tool for driver development. As such, it may be time for a
redesign in order to take into account its current use.

Beverly

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com

Sent: Wednesday, June 21, 2006 12:50 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] How to use SOURCES to compile on diferent paths.

If you say so. My point is, the driver development community is not
the
primary consumer of this utility, nor is its use in building drivers a
“design center” for the tool. In fact, the use of build in the DDK is
a
coincidental use of the tool, at best.

Build was originally designed by Steve Wood (now THERE’s a name you
don’t hear every day) back in 1989 as the tool that was used to build
Windows NT. To this day, they use it to build Windows (and a bunch of
other products as well) every day. They designed it, and they
apparently like it the way it works.

I guess that’s not a reason to stop raising issues with the tool. I’m
just trying to help set the expectations of community members about
the
chances of success.

Peter
OSR

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

15

> until, minimally, (1) Microsoft documents the compiler and linker

switches required/recommended to build drivers (as well as stop using
undocumented one); and (2) the preamble about only BUILD should be used
to build drivers is removed the documentation. The history aside, it’s
kind of ridiculous. On the other, it is free, used for other purposes,
and there is not a lot of incentive for Microsoft to spend the resources
to change it.
As far as I remember the flags as used by BUILD are all contained in
some make files (myriads of them actually). Still undocumented, but a
way to learn about all this…

16

Regarding the switches…

  • Microsoft pushes BUILD as a tool to build both kernel and user mode
    components.
  • The argument for kernel is that one gets a “consistent environment”.
  • I need my own switches for user mode components. The situation is
    reverse - Microsoft is free to change the makefiles in the future, which
    makes my user mode settings very fragile.
  • I have to dig into the makefiles to get BUILD to produce the switches I
    want. The documentation is useless - it’s simple impossible to document all
    the mess such as one in makefile.new.
  • Even worse, some switches are hard-coded. For example, it’s impossible
    remove /Oy- or /IGNORE:.
    - DDK includes outdated user mode headers. Some of them are missing. I need
    to include files from PSDK.
    - DDK 3790 includes buggy STL 6, while I need STL 7.
    - …and all that sort of rubbish.

    “Oliver” wrote in message news:xxxxx@ntdev…
    >> until, minimally, (1) Microsoft documents the compiler and linker
    >> switches required/recommended to build drivers (as well as stop using
    >> undocumented one); and (2) the preamble about only BUILD should be used
    >> to build drivers is removed the documentation. The history aside, it’s
    >> kind of ridiculous. On the other, it is free, used for other purposes,
    >> and there is not a lot of incentive for Microsoft to spend the resources
    >> to change it.
    > As far as I remember the flags as used by BUILD are all contained in
    > some make files (myriads of them actually). Still undocumented, but a
    > way to learn about all this…
    >
17

There’s a much easier and way that removes much of the guess work.
Build a paradigm project with BUILD, and look at the log file. It has
all the command lines.

MM

>> xxxxx@gmail.com 2006-06-21 16:53:54 >>>
until, minimally, (1) Microsoft documents the compiler and linker
switches required/recommended to build drivers (as well as stop
using
undocumented one); and (2) the preamble about only BUILD should be
used
to build drivers is removed the documentation. The history aside,
it’s
kind of ridiculous. On the other, it is free, used for other
purposes,
and there is not a lot of incentive for Microsoft to spend the
resources
to change it.
As far as I remember the flags as used by BUILD are all contained in
some make files (myriads of them actually). Still undocumented, but a
way to learn about all this…

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

18

NICK:

A simpler (and some ways less error prone) way to get the switches is
to build a paradigm target using BUILD and check out the log file for
the command lines (still obfuscated with information that means nothing
to me, but much less of it than MAKEFILE.DEF (& the platform specific
ones).

One of the first decisons I made once I finally got my first attempt at
a driver to build was not to use BUILD. I hate it. One of the reasons,
which I think relates to what you are talking about, is the weird CRT &
general link errors that result from using different settings and, in
some cases, different tools. With the arrival of managed versions of
assemblies for the VC runtime, I just finally gave up on dynamically
linking to them, and used LIBCMT (I would have prefered LIBC, but it is
no more). The recurring problem that I had that was just a pain in the
balls was that nothing would ever run on my test machines unless VC8.0
runtimes were installed. This got old really quickly. I don’t know the
types of problems you are having with the CRT, but this single change
made my life a lot easier.

I don’t know what you’re requirements are, but, based on my experience
and my needs (which involve some candian cross builds), I found it much,
much easier to write a system of makefiles (and a few batch files) that
did what I wanted than to even begin to consider learning and using any
other make system. I looked at the GNU autotools for about ten minutes
before my head began to hurt. It is not the greatest system, but, as
the work I do is almost entirely IR&D, they do what I need and I don’t
mind the significant constraints on directories, et. c., as I chose
them.

MM

>> xxxxx@cristalink.com 2006-06-21 17:25:51 >>>
Regarding the switches…

  • Microsoft pushes BUILD as a tool to build both kernel and user mode
    components.
  • The argument for kernel is that one gets a “consistent environment”.
  • I need my own switches for user mode components. The situation is
    reverse - Microsoft is free to change the makefiles in the future,
    which
    makes my user mode settings very fragile.
  • I have to dig into the makefiles to get BUILD to produce the switches
    I
    want. The documentation is useless - it’s simple impossible to document
    all
    the mess such as one in makefile.new.
  • Even worse, some switches are hard-coded. For example, it’s
    impossible
    remove /Oy- or /IGNORE:.
    - DDK includes outdated user mode headers. Some of them are missing. I
    need
    to include files from PSDK.
    - DDK 3790 includes buggy STL 6, while I need STL 7.
    - …and all that sort of rubbish.

    “Oliver” wrote in message news:xxxxx@ntdev…
    >> until, minimally, (1) Microsoft documents the compiler and linker
    >> switches required/recommended to build drivers (as well as stop
    using
    >> undocumented one); and (2) the preamble about only BUILD should be
    used
    >> to build drivers is removed the documentation. The history aside,
    it’s
    >> kind of ridiculous. On the other, it is free, used for other
    purposes,
    >> and there is not a lot of incentive for Microsoft to spend the
    resources
    >> to change it.
    > As far as I remember the flags as used by BUILD are all contained in
    > some make files (myriads of them actually). Still undocumented, but
    a
    > way to learn about all this…
    >

    —
    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
19

Martin,

>to build a paradigm target using BUILD and check out the log file for the
>command lines

That’s what I did once and then used for several years until now. So I know
what you mean.

Now I have multiple projects ranging from simple to very complex ones, mixed
kernel and user mode, some projects go out to customers and some are
internal. Some are for x86, x64 and IA-64.

Given all the above, I have decided to bite the bullet and migrate to that
bloody thing (BUILD). It has certain advantages once it’s set up and does
what I want. Well, not quite what I want, but something I can probably live
with.

P.S. I wonder why OSR wants my email address exposed in NTDEV? I am pretty
sure it’s the reason I am getting more spam.

“Martin O’Brien” wrote in message
news:xxxxx@ntdev…
> NICK:
>
> A simpler (and some ways less error prone) way to get the switches is
> to build a paradigm target using BUILD and check out the log file for
> the command lines (still obfuscated with information that means nothing
> to me, but much less of it than MAKEFILE.DEF (& the platform specific
> ones).
>
> One of the first decisons I made once I finally got my first attempt at
> a driver to build was not to use BUILD. I hate it. One of the reasons,
> which I think relates to what you are talking about, is the weird CRT &
> general link errors that result from using different settings and, in
> some cases, different tools. With the arrival of managed versions of
> assemblies for the VC runtime, I just finally gave up on dynamically
> linking to them, and used LIBCMT (I would have prefered LIBC, but it is
> no more). The recurring problem that I had that was just a pain in the
> balls was that nothing would ever run on my test machines unless VC8.0
> runtimes were installed. This got old really quickly. I don’t know the
> types of problems you are having with the CRT, but this single change
> made my life a lot easier.
>
> I don’t know what you’re requirements are, but, based on my experience
> and my needs (which involve some candian cross builds), I found it much,
> much easier to write a system of makefiles (and a few batch files) that
> did what I wanted than to even begin to consider learning and using any
> other make system. I looked at the GNU autotools for about ten minutes
> before my head began to hurt. It is not the greatest system, but, as
> the work I do is almost entirely IR&D, they do what I need and I don’t
> mind the significant constraints on directories, et. c., as I chose
> them.
>
> MM
>
>
>>>> xxxxx@cristalink.com 2006-06-21 17:25:51 >>>
> Regarding the switches…
>
> - Microsoft pushes BUILD as a tool to build both kernel and user mode
> components.
> - The argument for kernel is that one gets a “consistent environment”.
> - I need my own switches for user mode components. The situation is
> reverse - Microsoft is free to change the makefiles in the future,
> which
> makes my user mode settings very fragile.
> - I have to dig into the makefiles to get BUILD to produce the switches
> I
> want. The documentation is useless - it’s simple impossible to document
> all
> the mess such as one in makefile.new.
> - Even worse, some switches are hard-coded. For example, it’s
> impossible
> remove /Oy- or /IGNORE:.
> - DDK includes outdated user mode headers. Some of them are missing. I
> need
> to include files from PSDK.
> - DDK 3790 includes buggy STL 6, while I need STL 7.
> - …and all that sort of rubbish.
>
>
>
> “Oliver” wrote in message news:xxxxx@ntdev…
>>> until, minimally, (1) Microsoft documents the compiler and linker
>>> switches required/recommended to build drivers (as well as stop
> using
>>> undocumented one); and (2) the preamble about only BUILD should be
> used
>>> to build drivers is removed the documentation. The history aside,
> it’s
>>> kind of ridiculous. On the other, it is free, used for other
> purposes,
>>> and there is not a lot of incentive for Microsoft to spend the
> resources
>>> to change it.
>> As far as I remember the flags as used by BUILD are all contained in
>> some make files (myriads of them actually). Still undocumented, but
> a
>> way to learn about all this…
>>
>
>
>
> —
> 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
>

20

NICK:

I totally understand your decision, and, in some and perhaps most ways,
I think it makes more sense than what I did, which is go from BUILD to
custom. Ironically, our reasons seem to the same: multimode,
multiplatform, et. c.

MM

(P. S. - I also wonder about the spam thing, as I seem to get a fair
amount of it all pertaining to what the sender feels is my strong urge
to buy from online pharmacies. Curious, and, as this a work e-mail
address, most undesirable and unappreciated. Due to the later, I
rejected the idea of having someone who knows more about networking than
I do check it out to verify the source.)

>> xxxxx@cristalink.com 2006-06-21 19:16 >>>
Martin,

>to build a paradigm target using BUILD and check out the log file for
the
>command lines

That’s what I did once and then used for several years until now. So I
know
what you mean.

Now I have multiple projects ranging from simple to very complex ones,
mixed
kernel and user mode, some projects go out to customers and some are
internal. Some are for x86, x64 and IA-64.

Given all the above, I have decided to bite the bullet and migrate to
that
bloody thing (BUILD). It has certain advantages once it’s set up and
does
what I want. Well, not quite what I want, but something I can probably
live
with.

P.S. I wonder why OSR wants my email address exposed in NTDEV? I am
pretty
sure it’s the reason I am getting more spam.

“Martin O’Brien” wrote in message
news:xxxxx@ntdev…
> NICK:
>
> A simpler (and some ways less error prone) way to get the switches
is
> to build a paradigm target using BUILD and check out the log file
for
> the command lines (still obfuscated with information that means
nothing
> to me, but much less of it than MAKEFILE.DEF (& the platform
specific
> ones).
>
> One of the first decisons I made once I finally got my first attempt
at
> a driver to build was not to use BUILD. I hate it. One of the
reasons,
> which I think relates to what you are talking about, is the weird CRT
&
> general link errors that result from using different settings and,
in
> some cases, different tools. With the arrival of managed versions
of
> assemblies for the VC runtime, I just finally gave up on dynamically
> linking to them, and used LIBCMT (I would have prefered LIBC, but it
is
> no more). The recurring problem that I had that was just a pain in
the
> balls was that nothing would ever run on my test machines unless
VC8.0
> runtimes were installed. This got old really quickly. I don’t know
the
> types of problems you are having with the CRT, but this single
change
> made my life a lot easier.
>
> I don’t know what you’re requirements are, but, based on my
experience
> and my needs (which involve some candian cross builds), I found it
much,
> much easier to write a system of makefiles (and a few batch files)
that
> did what I wanted than to even begin to consider learning and using
any
> other make system. I looked at the GNU autotools for about ten
minutes
> before my head began to hurt. It is not the greatest system, but,
as
> the work I do is almost entirely IR&D, they do what I need and I
don’t
> mind the significant constraints on directories, et. c., as I chose
> them.
>
> MM
>
>
>>>> xxxxx@cristalink.com 2006-06-21 17:25:51 >>>
> Regarding the switches…
>
> - Microsoft pushes BUILD as a tool to build both kernel and user
mode
> components.
> - The argument for kernel is that one gets a “consistent
environment”.
> - I need my own switches for user mode components. The situation is
> reverse - Microsoft is free to change the makefiles in the future,
> which
> makes my user mode settings very fragile.
> - I have to dig into the makefiles to get BUILD to produce the
switches
> I
> want. The documentation is useless - it’s simple impossible to
document
> all
> the mess such as one in makefile.new.
> - Even worse, some switches are hard-coded. For example, it’s
> impossible
> remove /Oy- or /IGNORE:.
> - DDK includes outdated user mode headers. Some of them are missing.
I
> need
> to include files from PSDK.
> - DDK 3790 includes buggy STL 6, while I need STL 7.
> - …and all that sort of rubbish.
>
>
>
> “Oliver” wrote in message news:xxxxx@ntdev…
>>> until, minimally, (1) Microsoft documents the compiler and linker
>>> switches required/recommended to build drivers (as well as stop
> using
>>> undocumented one); and (2) the preamble about only BUILD should be
> used
>>> to build drivers is removed the documentation. The history aside,
> it’s
>>> kind of ridiculous. On the other, it is free, used for other
> purposes,
>>> and there is not a lot of incentive for Microsoft to spend the
> resources
>>> to change it.
>> As far as I remember the flags as used by BUILD are all contained
in
>> some make files (myriads of them actually). Still undocumented, but
> a
>> way to learn about all this…
>>
>
>
>
> —
> 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