WDK7 custom target path

[Tanya_Radeva]

Just a little ilustration for David to demonstrate where TARGETPATH screws up:

So we have the follwoing driver ptojects:
Project 1. Source code in: c:\WinDDK\base\abc\project
TARGETPATH is set to base\xyz\project$O

Project 2. Source code in: c:\WinDDK\base\xyz\project
No TARGETPATH set

In a build environment where separate object root is enabled all build output will go
in a folder separate from your source folder called object root or separate object root. The source code remains clean from the build output, immutable, can be placed on a CD, etc.

The separate object root places the build output in a tree structure that is exactly the same as your source tree structure. However, object root is a different folder.

By default the object tree is set to be %BASEDIR%.obj
Now where the build output will go for our 2 projects that we have in a separate object root environment:

Project1:
%BASEDIR%.obj\base\abc\project\objfre\i386 is the intuitive answer, but because we have TARGETPATH defined as base\xyz\project$O , the output will be in:
%BASEDIR%.obj\base\xyz\project\objfre\i386

Project 2:
The output simply goes in:
%BASEDIR%.obj\base\xyz\project\objfre\i386
No TARGETPATH for this project.

Now we have a build process that builds all the source tree c:\WinDDK\base.
The build output for Project1 and Project2 will endup in the same folder:
%BASEDIR%.obj\base\xyz\project\objfre\i386

[Peter_Viscarola_OSR]

That is, “beta” testing was only to find bugs in the product *as delivered*, not bugs relative to, let’s say, bad design decisions.

While this IS a rathole: Isn’t that part of the definition of the “Beta” stage of software testing?

You would have people making DESIGN changes at the Beta stage of the software lifecycle?? I sure wouldn’t. At least, not as a rule and not unless the design issue was a true show-stopper.

Peter
OSR

[OSR_Community_User]

I have found the same phenomenon in user space. There are still major
projects using VS6, and with each release of VS, the fact that moving
forward breaks things (including the user’s well-established workflow) means
there is negative incentive to move forward. If 90% of my clients are
building with VS2003, I can’t send them a project done in VS2005 or VS2008
because they can’t continue development. So I almost never use VS2008 for
anything, most of my work is VS2003, and finally, some clients are
supporting VS2005. It is not just the driver developers that suffer from
this. The issue here is that there is an entire ecosystem of developers,
customers of developers, and end users. Disruptive changes which seem to
add no functionality are not considered value-added; on the contrary, they
have profound negative value. If I’m feeding something into a customer that
has 1,000 VS2003 programmers or DDK version X programmers, they do not, and
in some cases cannot, move up to the latest VS or DDK/WDK, because it
disrupts the entire ecosystem. There is training, delayed product release,
need to recertify, productivity loss due to mixed-mode environments, etc.
Somehow, Microsoft just assumes that (a) all old projects convert instantly
and (b) new projects will naturally adopt the latest tools. This is
inconsistent with most forms of reality. We know that (a) is impossible,
and (b) involves new learing curves. Customers look for ROI (Return on
Investment) for training, and if they don’t see a recognizable gain they
will not “just do it” because it feels good. The case for improved tools
(e.g., VS Team Suite, PreFast, etc.) is not made strongly enough to convince
them to move on (VS was a particular embarrassment to most of us, because we
had to explain how a completely unusable GUI and broken critical features
“improved” productivity, which is why there are millions of lines of code
still being built in VS6).

One colleague once put it “Everything has to improve, and nothing can
change”. Key here is that changes, when the occur, have to be as
non-disruptive as they can possibly be made. “Big bang” changes (VS
2002+/VS6, Office 2007/2003, WDK7/DDK) which do not have apparent
value-added but are major disruptions will not be adopted readily, or in
some cases, at all.
joe

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Saturday, January 17, 2009 5:41 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] WDK7 custom target path

I suspect binplace is a better approach, but the problem is that it still is
a change, and having a change leads to several problems:

1. Getting my clients to use the beta. Since they have to change
   their working code to try the beta they are much less likely to try it,
   especially since most of them are in cycles of getting out new drivers

2. Backwards compatibility is broken. I still have clients who build
   some drivers with 3790.1830 because they have not had justification to move
   forward. Even for these customers I push them to run the latest prefast on
   the driver and validate things, but here it means keeping a SOURCES for the
   old environment and a SOURCES for the new environment.

Please remember any change has consequences, and these changes have in some
cases made clients reluctant to take the step to better tools.

–
Don Burn (MVP, Windows DDK)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

wrote in message news:xxxxx@ntdev…
> Yes, Binplace sample is a good alternative to what you want to achieve -
> binaries placed in a custom folder.
>
> To turn on that just add separate_object_root flag as setenv.bat
> parameter.
>
> Then you specify TARGET_DESTINATION = customfolder
>
> The result:
>
> Source code in: c:\WinDDK\base\abc\project
> TARGET_DESTINATION = customfolder
> Output will result in: c:\WinDDK.binaries..\customfolder
>
>

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

–
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

[OSR_Community_User]

But that’s my point: for some design decisions, the changes *are*
show-stoppers. Which is why the practicing professionals need to be in on
the design decisions *early*. Beta-testing is far too late, but feedback
that says “this is unusable” has no impact.
joe

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
Sent: Sunday, January 18, 2009 2:06 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] WDK7 custom target path

That is, “beta” testing was only to find bugs in the product *as delivered*,
not bugs relative to, let’s say, bad design decisions.

While this IS a rathole: Isn’t that part of the definition of the “Beta”
stage of software testing?

You would have people making DESIGN changes at the Beta stage of the
software lifecycle?? I sure wouldn’t. At least, not as a rule and not
unless the design issue was a true show-stopper.

Peter
OSR

---

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

–
This message has been scanned for viruses and dangerous content by
MailScanner, and is believed to be clean.

[OSR_Community_User]

I always become curious why environment variables are thought to be so cool.
Shouldn’t all of this be incorporated into a parameter file (e.g., sources).
The point of TARGETPATH was that it put the information where it belonged:
as part of the project parameters, not as some random external piece of
state that had to be maintained by a completely separate mechanism, whose
interactions are not understood or in some cases even seen?
joe

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@microsoft.com
Sent: Saturday, January 17, 2009 5:35 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] WDK7 custom target path

Yes, Binplace sample is a good alternative to what you want to achieve -
binaries placed in a custom folder.

To turn on that just add separate_object_root flag as setenv.bat parameter.

Then you specify TARGET_DESTINATION = customfolder

The result:

Source code in: c:\WinDDK\base\abc\project TARGET_DESTINATION = customfolder
Output will result in: c:\WinDDK.binaries..\customfolder

---

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

–
This message has been scanned for viruses and dangerous content by
MailScanner, and is believed to be clean.

[David_R_Cattley]

Tanya,

Thanks.

If I have this right, TARGETPATH collides with a new feature (maybe it is an
old feature) that allows the entire build ‘output’ to be placed under a
different path.

Do I infer properly then that the new feature became necessary for the OS
team and now TARGETPATH *cannot* be used (as-is) when that redirection is in
place?

What about the case where that redirection is *not* in use (aka, how the WDK
consumers typically build)? Is it a challenge (or impossibility) to have
MAKEFILE.DEF (and/or the rules verification include) just bitch and stop if
TARGETPATH is set *and* the object root redirection is enabled?

I’m really not trying to second-guess or redesign this thing. I am asking
the questions to be sure I fully understand the situation.

Cheers,
-dave

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@microsoft.com
Sent: Sunday, January 18, 2009 2:04 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] WDK7 custom target path

Just a little ilustration for David to demonstrate where TARGETPATH screws
up:

So we have the follwoing driver ptojects:
Project 1. Source code in: c:\WinDDK\base\abc\project
TARGETPATH is set to base\xyz\project$O

Project 2. Source code in: c:\WinDDK\base\xyz\project
No TARGETPATH set

In a build environment where separate object root is enabled all build
output will go
in a folder separate from your source folder called object root or separate
object root. The source code remains clean from the build output, immutable,
can be placed on a CD, etc.

The separate object root places the build output in a tree structure that is
exactly the same as your source tree structure. However, object root is a
different folder.

By default the object tree is set to be %BASEDIR%.obj
Now where the build output will go for our 2 projects that we have in a
separate object root environment:

Project1:
%BASEDIR%.obj\base\abc\project\objfre\i386 is the intuitive answer, but
because we have TARGETPATH defined as base\xyz\project$O , the output will
be in:
%BASEDIR%.obj\base\xyz\project\objfre\i386

Project 2:
The output simply goes in:
%BASEDIR%.obj\base\xyz\project\objfre\i386
No TARGETPATH for this project.

Now we have a build process that builds all the source tree c:\WinDDK\base.
The build output for Project1 and Project2 will endup in the same folder:
%BASEDIR%.obj\base\xyz\project\objfre\i386

---

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

[OSR_Community_User]

I don’t think that this will change the behavior, but have you tried
experimenting with ‘separate_object_root’ on the setenv.bat command line?

mm

David R. Cattley wrote:

Tanya,

Thanks.

If I have this right, TARGETPATH collides with a new feature (maybe it is an
old feature) that allows the entire build ‘output’ to be placed under a
different path.

Do I infer properly then that the new feature became necessary for the OS
team and now TARGETPATH *cannot* be used (as-is) when that redirection is in
place?

What about the case where that redirection is *not* in use (aka, how the WDK
consumers typically build)? Is it a challenge (or impossibility) to have
MAKEFILE.DEF (and/or the rules verification include) just bitch and stop if
TARGETPATH is set *and* the object root redirection is enabled?

I’m really not trying to second-guess or redesign this thing. I am asking
the questions to be sure I fully understand the situation.

Cheers,
-dave

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@microsoft.com
Sent: Sunday, January 18, 2009 2:04 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] WDK7 custom target path

Just a little ilustration for David to demonstrate where TARGETPATH screws
up:

So we have the follwoing driver ptojects:
Project 1. Source code in: c:\WinDDK\base\abc\project
TARGETPATH is set to base\xyz\project$O

Project 2. Source code in: c:\WinDDK\base\xyz\project
No TARGETPATH set

In a build environment where separate object root is enabled all build
output will go
in a folder separate from your source folder called object root or separate
object root. The source code remains clean from the build output, immutable,
can be placed on a CD, etc.

The separate object root places the build output in a tree structure that is
exactly the same as your source tree structure. However, object root is a
different folder.

By default the object tree is set to be %BASEDIR%.obj
Now where the build output will go for our 2 projects that we have in a
separate object root environment:

Project1:
%BASEDIR%.obj\base\abc\project\objfre\i386 is the intuitive answer, but
because we have TARGETPATH defined as base\xyz\project$O , the output will
be in:
%BASEDIR%.obj\base\xyz\project\objfre\i386

Project 2:
The output simply goes in:
%BASEDIR%.obj\base\xyz\project\objfre\i386
No TARGETPATH for this project.

Now we have a build process that builds all the source tree c:\WinDDK\base.
The build output for Project1 and Project2 will endup in the same folder:
%BASEDIR%.obj\base\xyz\project\objfre\i386

---

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

[Tanya_Radeva]

Yes separate object root is a dominant in Windows build so by removing TARGETPATH a lot of collisions are solved. In WDK it is an optional feature because we do not want to break the way the driver developers built they drivers so far.

Although TARGETPATH is deprecated in Windows for good reasons, those reasons are insignificant in small projects.

We are considering to restore TARGETPATH just for WDK.

Thanks,
Tanya

[OSR_Community_User]

> Please remember any change has consequences, and these changes have
in some cases made clients reluctant to take the step to better tools.

Exactly. In my opinion, if it must come up at all, this is context in
which the question ‘do we need a new installer’ should be asked.

mm

Don Burn wrote:

I suspect binplace is a better approach, but the problem is that it still is
a change, and having a change leads to several problems:

1. Getting my clients to use the beta. Since they have to change
   their working code to try the beta they are much less likely to try it,
   especially since most of them are in cycles of getting out new drivers

2. Backwards compatibility is broken. I still have clients who build
   some drivers with 3790.1830 because they have not had justification to move
   forward. Even for these customers I push them to run the latest prefast on
   the driver and validate things, but here it means keeping a SOURCES for the
   old environment and a SOURCES for the new environment.

Please remember any change has consequences, and these changes have in some
cases made clients reluctant to take the step to better tools.

[OSR_Community_User]

I’m glad to hear that I’m not alone in wondering about the value that
BUILD does or does not provide. I mean, sure it provides a ‘standard,’
but the same thing could be achieved by them just documenting the
command line options involved, it’s a standard that is not exactly
without issue, and, well, it’s not really a standard either, as gets
highlighted from time to time. I’m not saying that rolling your own
BUILD environment in the form of makefiles is necessarily a good idea in
most cases, mainly because you’re going to get zero support, and I
gather a complete deal breaker with the WHQL folks, but the idea that
incorrect command line options are even a chartable cause of drivers
failing as compared to, say, what people screw up, is just ridiculous,
in my opinion. It can happen, but if they were available, I’m thinking
that someone who can otherwise produce a correctly functioning driver
could swing writing a makefile, but that would depend on msft correctly
documenting and updating the command line options, which msft could
probably not swing.

My major irritation with BUILD is that it’s a required tool that’s
basically unmaintained - as in fixing defects, like dependency checking

• that is evangelized as THE ONE AND ONLY way, and imposes a very rigid
  structure on your source tree.

mm

Mark Roddy wrote:

It seems they changed build.exe. I’ve never quite understood what
build.exe was doing for me other than being a block-box standing in the
way of just using makefiles to build stuff. Now it seems it really does
have some use: it randomly changes and in doing so forces developers all
around the planet to change working processes for building software.

Mark Roddy

On Sat, Jan 17, 2009 at 8:21 PM, Lyndon J Clarke
> wrote:
>
> Doron
>
> Can you give one good reason for removal of TARGETPATH?
>
> Thanks, Lyndon
>
> “Doron Holan” > mailto:xxxxx> wrote in message
> news:xxxxx@ntdev…
> Have you looked at BINPLACE? That will copy the resulting bins in
> whatever
> dir you want independent of where the compiler generated the binary.
> Seems
> to me you can just replace targetpath with it
>
> d
>
> Sent from my phone with no t9, all spilling mistakes are not
> intentional.
>
> -----Original Message-----
> From: Maxim S. Shatskih > mailto:xxxxx>
> Sent: Saturday, January 17, 2009 11:52 AM
> To: Windows System Software Devs Interest List > mailto:xxxxx>
> Subject: Re:[ntdev] WDK7 custom target path
>
>
> >I noticed TARGETPATH (and TARGETPATHLIB) are no longer supported
> in WDK7.
>
> I second this.
>
> TARGETPATH is a very important feature which allows to build lots of
> EXE/DLL/SYS files using one “build” command, and then to place all
> of them
> to a single directory for convinience.
>
> Also, I use LIB files for intermediate stages of BUILD, and putting
> them to
> a single directory using TARGETPATH is a good idea again.
>
> People do really use TARGETPATH. It is a good thing, and too bad it is
> removed from Win7 DDK beta.
>
> –
> Maxim S. Shatskih
> Windows DDK MVP
> xxxxx@storagecraft.com mailto:xxxxx
> http://www.storagecraft.com
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx>

[OSR_Community_User]

Perhaps if BUILD supported conditional compilation and otherwise worked
like nmake, or if it were at least documented what it does and does not
support, it would be possible to change things without changing BUILD in
incompatible ways, and it might also allow one to try out a beta without
breaking existing use of existing WDK’s. That is, something like:

!IF (“$(separate_object_root)” != “”)

…

Now, it may be the case that this was an option, and the Windows team
just changed BUILD anyway; I really don’t know, because the mysteries of
the processing of SOURCES are dark and deep.

This would seem like a very useful capability to have going forward, and
it’s certainly not a hard problem.

mm

David R. Cattley wrote:

Tanya,

Thanks.

If I have this right, TARGETPATH collides with a new feature (maybe it is an
old feature) that allows the entire build ‘output’ to be placed under a
different path.

Do I infer properly then that the new feature became necessary for the OS
team and now TARGETPATH *cannot* be used (as-is) when that redirection is in
place?

What about the case where that redirection is *not* in use (aka, how the WDK
consumers typically build)? Is it a challenge (or impossibility) to have
MAKEFILE.DEF (and/or the rules verification include) just bitch and stop if
TARGETPATH is set *and* the object root redirection is enabled?

I’m really not trying to second-guess or redesign this thing. I am asking
the questions to be sure I fully understand the situation.

Cheers,
-dave

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@microsoft.com
Sent: Sunday, January 18, 2009 2:04 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] WDK7 custom target path

Just a little ilustration for David to demonstrate where TARGETPATH screws
up:

So we have the follwoing driver ptojects:
Project 1. Source code in: c:\WinDDK\base\abc\project
TARGETPATH is set to base\xyz\project$O

Project 2. Source code in: c:\WinDDK\base\xyz\project
No TARGETPATH set

In a build environment where separate object root is enabled all build
output will go
in a folder separate from your source folder called object root or separate
object root. The source code remains clean from the build output, immutable,
can be placed on a CD, etc.

The separate object root places the build output in a tree structure that is
exactly the same as your source tree structure. However, object root is a
different folder.

By default the object tree is set to be %BASEDIR%.obj
Now where the build output will go for our 2 projects that we have in a
separate object root environment:

Project1:
%BASEDIR%.obj\base\abc\project\objfre\i386 is the intuitive answer, but
because we have TARGETPATH defined as base\xyz\project$O , the output will
be in:
%BASEDIR%.obj\base\xyz\project\objfre\i386

Project 2:
The output simply goes in:
%BASEDIR%.obj\base\xyz\project\objfre\i386
No TARGETPATH for this project.

Now we have a build process that builds all the source tree c:\WinDDK\base.
The build output for Project1 and Project2 will endup in the same folder:
%BASEDIR%.obj\base\xyz\project\objfre\i386

---

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

[Michael_Jones]

Since the community inherits the build environment that’s used to build
Windows, that means it’s more difficult for the WDK team to make major
changes to the base tools in the WDK build environment. Do you REALLY
want a build environment that diverges significantly from that used to
build the OS?? I know that I sure don’t.

[/quote]


On the other hand, we are admonished to always use the latest [DW]DK to
build our drivers, even for older OS versions. So, every time they
change the build process, it diverges from the environment used to build
those older OS versions…I wonder how much the WDK7 has evolved from,
say, the Win2K environment?

Cheers,

– mkj

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

[Mark_Roddy]

I personally think build.exe provides very little real added value that
could not be achieved using a standardized set of makefiles, a few assorted
shell scripts etc. all of which would be open to inspection and
understanding by developers.The WDK could still provide a structured
supportable build environment, it just would no longer depend on a poorly
documented poorly understood and totally nonstandard build tool.

Mark Roddy

On Sun, Jan 18, 2009 at 3:37 PM, Martin O’Brien
wrote:

> I’m glad to hear that I’m not alone in wondering about the value that BUILD
> does or does not provide. I mean, sure it provides a ‘standard,’ but the
> same thing could be achieved by them just documenting the command line
> options involved, it’s a standard that is not exactly without issue, and,
> well, it’s not really a standard either, as gets highlighted from time to
> time. I’m not saying that rolling your own BUILD environment in the form of
> makefiles is necessarily a good idea in most cases, mainly because you’re
> going to get zero support, and I gather a complete deal breaker with the
> WHQL folks, but the idea that incorrect command line options are even a
> chartable cause of drivers failing as compared to, say, what people screw
> up, is just ridiculous, in my opinion. It can happen, but if they were
> available, I’m thinking that someone who can otherwise produce a correctly
> functioning driver could swing writing a makefile, but that would depend on
> msft correctly documenting and updating the command line options, which msft
> could probably not swing.
>
> My major irritation with BUILD is that it’s a required tool that’s
> basically unmaintained - as in fixing defects, like dependency checking -
> that is evangelized as THE ONE AND ONLY way, and imposes a very rigid
> structure on your source tree.
>
> mm
>
>
>
>
>
>
>
> Mark Roddy wrote:
>
>> It seems they changed build.exe. I’ve never quite understood what
>> build.exe was doing for me other than being a block-box standing in the way
>> of just using makefiles to build stuff. Now it seems it really does have
>> some use: it randomly changes and in doing so forces developers all around
>> the planet to change working processes for building software.
>>
>>
>>
>> Mark Roddy
>>
>>
>> On Sat, Jan 17, 2009 at 8:21 PM, Lyndon J Clarke <
>> xxxxx@neverfailgroup.com mailto:xxxxx> wrote:
>>
>> Doron
>>
>> Can you give one good reason for removal of TARGETPATH?
>>
>> Thanks, Lyndon
>>
>> “Doron Holan” >> mailto:xxxxx> wrote in message
>> news:xxxxx@ntdev…
>> Have you looked at BINPLACE? That will copy the resulting bins in
>> whatever
>> dir you want independent of where the compiler generated the binary.
>> Seems
>> to me you can just replace targetpath with it
>>
>> d
>>
>> Sent from my phone with no t9, all spilling mistakes are not
>> intentional.
>>
>> -----Original Message-----
>> From: Maxim S. Shatskih >> mailto:xxxxx>
>> Sent: Saturday, January 17, 2009 11:52 AM
>> To: Windows System Software Devs Interest List >> mailto:xxxxx>
>> Subject: Re:[ntdev] WDK7 custom target path
>>
>>
>> >I noticed TARGETPATH (and TARGETPATHLIB) are no longer supported
>> in WDK7.
>>
>> I second this.
>>
>> TARGETPATH is a very important feature which allows to build lots of
>> EXE/DLL/SYS files using one “build” command, and then to place all
>> of them
>> to a single directory for convinience.
>>
>> Also, I use LIB files for intermediate stages of BUILD, and putting
>> them to
>> a single directory using TARGETPATH is a good idea again.
>>
>> People do really use TARGETPATH. It is a good thing, and too bad it is
>> removed from Win7 DDK beta.
>>
>> –
>> Maxim S. Shatskih
>> Windows DDK MVP
>> xxxxx@storagecraft.com mailto:xxxxx
>> http://www.storagecraft.com
>>
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>>
>>
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>>
>>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx>

[OSR_Community_User]

Exactly

mm

Mark Roddy wrote:

I personally think build.exe provides very little real added value that
could not be achieved using a standardized set of makefiles, a few
assorted shell scripts etc. all of which would be open to inspection and
understanding by developers.The WDK could still provide a structured
supportable build environment, it just would no longer depend on a
poorly documented poorly understood and totally nonstandard build tool.

Mark Roddy

On Sun, Jan 18, 2009 at 3:37 PM, Martin O’Brien
> wrote:
>
> I’m glad to hear that I’m not alone in wondering about the value
> that BUILD does or does not provide. I mean, sure it provides a
> ‘standard,’ but the same thing could be achieved by them just
> documenting the command line options involved, it’s a standard that
> is not exactly without issue, and, well, it’s not really a standard
> either, as gets highlighted from time to time. I’m not saying that
> rolling your own BUILD environment in the form of makefiles is
> necessarily a good idea in most cases, mainly because you’re going
> to get zero support, and I gather a complete deal breaker with the
> WHQL folks, but the idea that incorrect command line options are
> even a chartable cause of drivers failing as compared to, say, what
> people screw up, is just ridiculous, in my opinion. It can happen,
> but if they were available, I’m thinking that someone who can
> otherwise produce a correctly functioning driver could swing writing
> a makefile, but that would depend on msft correctly documenting and
> updating the command line options, which msft could probably not swing.
>
> My major irritation with BUILD is that it’s a required tool that’s
> basically unmaintained - as in fixing defects, like dependency
> checking - that is evangelized as THE ONE AND ONLY way, and imposes
> a very rigid structure on your source tree.
>
> mm
>
>
>
>
>
>
>
> Mark Roddy wrote:
>
> It seems they changed build.exe. I’ve never quite understood
> what build.exe was doing for me other than being a block-box
> standing in the way of just using makefiles to build stuff. Now
> it seems it really does have some use: it randomly changes and
> in doing so forces developers all around the planet to change
> working processes for building software.
>
>
>
> Mark Roddy
>
>
> On Sat, Jan 17, 2009 at 8:21 PM, Lyndon J Clarke
>
> mailto:xxxxx> mailto:xxxxx>> wrote:
>
> Doron
>
> Can you give one good reason for removal of TARGETPATH?
>
> Thanks, Lyndon
>
> “Doron Holan” > mailto:xxxxx
> mailto:xxxxx> mailto:xxxxx>> wrote in message
>
> news:xxxxx@ntdev…
> Have you looked at BINPLACE? That will copy the resulting bins in
> whatever
> dir you want independent of where the compiler generated the
> binary.
> Seems
> to me you can just replace targetpath with it
>
> d
>
> Sent from my phone with no t9, all spilling mistakes are not
> intentional.
>
> -----Original Message-----
> From: Maxim S. Shatskih > mailto:xxxxx
> mailto:xxxxx>>
> Sent: Saturday, January 17, 2009 11:52 AM
> To: Windows System Software Devs Interest List
>
> mailto:xxxxx>>
> Subject: Re:[ntdev] WDK7 custom target path
>
>
> >I noticed TARGETPATH (and TARGETPATHLIB) are no longer
> supported
> in WDK7.
>
> I second this.
>
> TARGETPATH is a very important feature which allows to build
> lots of
> EXE/DLL/SYS files using one “build” command, and then to
> place all
> of them
> to a single directory for convinience.
>
> Also, I use LIB files for intermediate stages of BUILD, and
> putting
> them to
> a single directory using TARGETPATH is a good idea again.
>
> People do really use TARGETPATH. It is a good thing, and too
> bad it is
> removed from Win7 DDK beta.
>
> –
> Maxim S. Shatskih
> Windows DDK MVP
> xxxxx@storagecraft.com mailto:xxxxx
> mailto:xxxxx>
>
> http://www.storagecraft.com
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx>

[Calvin_Guan-2]

Yay.?Getting?rid of build.exe but document the?nmake targets, macros?be a nice thing to see. You’ve got my vote.

Calvin

---

From: Mark Roddy
To: Windows System Software Devs Interest List
Sent: Sunday, January 18, 2009 8:18:31 PM
Subject: Re: [ntdev] WDK7 custom target path

I personally think build.exe provides very little real added value that could not be?achieved?using a standardized set of makefiles, a few assorted shell scripts etc. all of which would be open to inspection and understanding by developers.The WDK could still provide a structured supportable build environment, it just would no longer depend on a poorly documented poorly understood and totally nonstandard build tool.

Mark Roddy

On Sun, Jan 18, 2009 at 3:37 PM, Martin O’Brien wrote:

I’m glad to hear that I’m not alone in wondering about the value that BUILD does or does not provide. ?I mean, sure it provides a ‘standard,’ but the same thing could be achieved by them just documenting the command line options involved, it’s a standard that is not exactly without issue, and, well, it’s not really a standard either, as gets highlighted from time to time. ?I’m not saying that rolling your own BUILD environment in the form of makefiles is necessarily a good idea in most cases, mainly because you’re going to get zero support, and I gather a complete deal breaker with the WHQL folks, but the idea that incorrect command line options are even a chartable cause of drivers failing as compared to, say, what people screw up, is just ridiculous, in my opinion. ?It can happen, but if they were available, I’m thinking that someone who can otherwise produce a correctly functioning driver could swing writing a makefile, but that would depend on
msft correctly documenting and updating the command line options, which msft could probably not swing.

My major irritation with BUILD is that it’s a required tool that’s basically unmaintained - as in fixing defects, like dependency checking - that is evangelized as THE ONE AND ONLY way, and imposes a very rigid structure on your source tree.

mm

Mark Roddy wrote:

It seems they changed build.exe. I’ve never quite understood what build.exe was doing for me other than being a block-box standing in the way of just using makefiles to build stuff. Now it seems it really does have some use: it randomly changes and in doing so forces developers all around the planet to change working processes for building software.

Mark Roddy

On Sat, Jan 17, 2009 at 8:21 PM, Lyndon J Clarke > wrote:

? ?Doron

? ?Can you give one good reason for removal of TARGETPATH?

? ?Thanks, Lyndon

? ?“Doron Holan” ? ?mailto:xxxxx> wrote in message

? ?news:xxxxx@ntdev…
? ?Have you looked at BINPLACE? That will copy the resulting bins in
? ?whatever
? ?dir you want independent of where the compiler generated the binary.
? ?Seems
? ?to me you can just replace targetpath with it

? ?d

? ?Sent from my phone with no t9, all spilling mistakes are not
? ?intentional.

? ?-----Original Message-----
? ?From: Maxim S. Shatskih
? ?mailto:xxxxx>
? ?Sent: Saturday, January 17, 2009 11:52 AM
? ?To: Windows System Software Devs Interest List
? ?mailto:xxxxx>
? ?Subject: Re:[ntdev] WDK7 custom target path

? ? >I noticed TARGETPATH (and TARGETPATHLIB) are no longer supported
? ?in WDK7.

? ?I second this.

? ?TARGETPATH is a very important feature which allows to build lots of
? ?EXE/DLL/SYS files using one “build” command, and then to place all
? ?of them
? ?to a single directory for convinience.

? ?Also, I use LIB files for intermediate stages of BUILD, and putting
? ?them to
? ?a single directory using TARGETPATH is a good idea again.

? ?People do really use TARGETPATH. It is a good thing, and too bad it is
? ?removed from Win7 DDK beta.

? ?–
? ?Maxim S. Shatskih
? ?Windows DDK MVP
? ?xxxxx@storagecraft.com mailto:xxxxx

? ?http://www.storagecraft.com

? ?—
? ?NTDEV is sponsored by OSR

? ?For our schedule of WDF, WDM, debugging and other seminars visit:
? ?http://www.osr.com/seminars

? ?To unsubscribe, visit the List Server section of OSR Online at
? ?http://www.osronline.com/page.cfm?name=ListServer

? ?—
? ?NTDEV is sponsored by OSR

? ?For our schedule of WDF, WDM, debugging and other seminars visit:
? ?http://www.osr.com/seminars

? ?To unsubscribe, visit the List Server section of OSR Online at
? ?http://www.osronline.com/page.cfm?name=ListServer

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

— NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer</mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx>

[Le_Huang-2]

I got the same question as Michael did when reading Peter’s message. Any comments about this?

Michael Jones wrote:

> Since the community inherits the build environment that’s used to build
> Windows, that means it’s more difficult for the WDK team to make major
> changes to the base tools in the WDK build environment. Do you REALLY
> want a build environment that diverges significantly from that used to
> build the OS?? I know that I sure don’t.
>
[/quote]

>
> On the other hand, we are admonished to always use the latest [DW]DK to
> build our drivers, even for older OS versions. So, every time they
> change the build process, it diverges from the environment used to build
> those older OS versions…I wonder how much the WDK7 has evolved from,
> say, the Win2K environment?

[Pavel_A1]

In other words, you want entirely make-based build system, like in Linux.
However, if MS were to break from their old good toolchain, they
could abandon the nmake and makefiles altogether, and go to something
completely different, like the .NET msbuild (nant-like)?

Regards,
–PA

Calvin Guan wrote:

Yay. Getting rid of build.exe but document the nmake targets, macros be
a nice thing to see. You’ve got my vote.

Calvin

*From:* Mark Roddy
> To: Windows System Software Devs Interest List
> Sent: Sunday, January 18, 2009 8:18:31 PM
> Subject: Re: [ntdev] WDK7 custom target path
>
> I personally think build.exe provides very little real added value that
> could not be achieved using a standardized set of makefiles, a few
> assorted shell scripts etc. all of which would be open to inspection and
> understanding by developers.The WDK could still provide a structured
> supportable build environment, it just would no longer depend on a
> poorly documented poorly understood and totally nonstandard build tool.
>
> Mark Roddy
>
>
> On Sun, Jan 18, 2009 at 3:37 PM, Martin O’Brien
> > wrote:
>
> I’m glad to hear that I’m not alone in wondering about the value
> that BUILD does or does not provide. I mean, sure it provides a
> ‘standard,’ but the same thing could be achieved by them just
> documenting the command line options involved, it’s a standard that
> is not exactly without issue, and, well, it’s not really a standard
> either, as gets highlighted from time to time. I’m not saying that
> rolling your own BUILD environment in the form of makefiles is
> necessarily a good idea in most cases, mainly because you’re going
> to get zero support, and I gather a complete deal breaker with the
> WHQL folks, but the idea that incorrect command line options are
> even a chartable cause of drivers failing as compared to, say, what
> people screw up, is just ridiculous, in my opinion. It can happen,
> but if they were available, I’m thinking that someone who can
> otherwise produce a correctly functioning driver could swing writing
> a makefile, but that would depend on msft correctly documenting and
> updating the command line options, which msft could probably not swing.
>
> My major irritation with BUILD is that it’s a required tool that’s
> basically unmaintained - as in fixing defects, like dependency
> checking - that is evangelized as THE ONE AND ONLY way, and imposes
> a very rigid structure on your source tree.
>
> mm
>
>
>
>
>
>
>
> Mark Roddy wrote:
>
> It seems they changed build.exe. I’ve never quite understood
> what build.exe was doing for me other than being a block-box
> standing in the way of just using makefiles to build stuff. Now
> it seems it really does have some use: it randomly changes and
> in doing so forces developers all around the planet to change
> working processes for building software.
>
>
>
> Mark Roddy
>
>
> On Sat, Jan 17, 2009 at 8:21 PM, Lyndon J Clarke
>
> mailto:xxxxx> mailto:xxxxx>> wrote:
>
> Doron
>
> Can you give one good reason for removal of TARGETPATH?
>
> Thanks, Lyndon
>
> “Doron Holan” > mailto:xxxxx
> mailto:xxxxx> mailto:xxxxx>> wrote in message
>
> news:xxxxx@ntdev…
> Have you looked at BINPLACE? That will copy the resulting bins in
> whatever
> dir you want independent of where the compiler generated the
> binary.
> Seems
> to me you can just replace targetpath with it
>
> d
>
> Sent from my phone with no t9, all spilling mistakes are not
> intentional.
>
> -----Original Message-----
> From: Maxim S. Shatskih > mailto:xxxxx
> mailto:xxxxx>>
> Sent: Saturday, January 17, 2009 11:52 AM
> To: Windows System Software Devs Interest List
>
> mailto:xxxxx>>
> Subject: Re:[ntdev] WDK7 custom target path
>
>
> >I noticed TARGETPATH (and TARGETPATHLIB) are no longer
> supported
> in WDK7.
>
> I second this.
>
> TARGETPATH is a very important feature which allows to build
> lots of
> EXE/DLL/SYS files using one “build” command, and then to
> place all
> of them
> to a single directory for convinience.
>
> Also, I use LIB files for intermediate stages of BUILD, and
> putting
> them to
> a single directory using TARGETPATH is a good idea again.
>
> People do really use TARGETPATH. It is a good thing, and too
> bad it is
> removed from Win7 DDK beta.
>
> –
> Maxim S. Shatskih
> Windows DDK MVP
> xxxxx@storagecraft.com mailto:xxxxx
> mailto:xxxxx>
>
> http://www.storagecraft.com http:</http:>
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
> — NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging
> and other seminars visit: http://www.osr.com/seminars To unsubscribe,
> visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx>

[OSR_Community_User]

That’s what I would like as an option. Make that is, (ideally a real
‘make,’ not nmake, but that would be totally incompatible), definitely
not msbuild. That’s what they almost have already; there’s just no
documentation and BUILD’s in the way, not doing a whole lot other than
confusing the process. In point of fact, as I learned fairly recently,
once BUILD has generated _objects.mac, you can just run nmake. In some
cases, especially how conditional compilation works in SOURCES, BUILD
greatly confuses people and limits what you can do, in my opinion.

MSBuild is one of those tools that exhibits such complexity that it
makes my head hurt to read about it. Most driver projects are very
simple in structure, so I don’t personally see the value added by a
complex build system, but then again, I really am not all that familiar
with MSBuild.

mm

Pavel A. wrote:

In other words, you want entirely make-based build system, like in Linux.
However, if MS were to break from their old good toolchain, they
could abandon the nmake and makefiles altogether, and go to something
completely different, like the .NET msbuild (nant-like)?

Regards,
–PA

Calvin Guan wrote:
>
> Yay. Getting rid of build.exe but document the nmake targets, macros
> be a nice thing to see. You’ve got my vote.
>
> Calvin
>
> *From:* Mark Roddy
>> To: Windows System Software Devs Interest List
>> Sent: Sunday, January 18, 2009 8:18:31 PM
>> Subject: Re: [ntdev] WDK7 custom target path
>>
>> I personally think build.exe provides very little real added value
>> that could not be achieved using a standardized set of makefiles, a
>> few assorted shell scripts etc. all of which would be open to
>> inspection and understanding by developers.The WDK could still provide
>> a structured supportable build environment, it just would no longer
>> depend on a poorly documented poorly understood and totally
>> nonstandard build tool.
>>
>> Mark Roddy
>>
>>
>> On Sun, Jan 18, 2009 at 3:37 PM, Martin O’Brien
>> > wrote:
>>
>> I’m glad to hear that I’m not alone in wondering about the value
>> that BUILD does or does not provide. I mean, sure it provides a
>> ‘standard,’ but the same thing could be achieved by them just
>> documenting the command line options involved, it’s a standard that
>> is not exactly without issue, and, well, it’s not really a standard
>> either, as gets highlighted from time to time. I’m not saying that
>> rolling your own BUILD environment in the form of makefiles is
>> necessarily a good idea in most cases, mainly because you’re going
>> to get zero support, and I gather a complete deal breaker with the
>> WHQL folks, but the idea that incorrect command line options are
>> even a chartable cause of drivers failing as compared to, say, what
>> people screw up, is just ridiculous, in my opinion. It can happen,
>> but if they were available, I’m thinking that someone who can
>> otherwise produce a correctly functioning driver could swing writing
>> a makefile, but that would depend on msft correctly documenting and
>> updating the command line options, which msft could probably not
>> swing.
>>
>> My major irritation with BUILD is that it’s a required tool that’s
>> basically unmaintained - as in fixing defects, like dependency
>> checking - that is evangelized as THE ONE AND ONLY way, and imposes
>> a very rigid structure on your source tree.
>>
>> mm
>>
>>
>>
>>
>>
>>
>>
>> Mark Roddy wrote:
>>
>> It seems they changed build.exe. I’ve never quite understood
>> what build.exe was doing for me other than being a block-box
>> standing in the way of just using makefiles to build stuff. Now
>> it seems it really does have some use: it randomly changes and
>> in doing so forces developers all around the planet to change
>> working processes for building software.
>>
>>
>>
>> Mark Roddy
>>
>>
>> On Sat, Jan 17, 2009 at 8:21 PM, Lyndon J Clarke
>>
>> mailto:xxxxx>> mailto:xxxxx>> wrote:
>>
>> Doron
>>
>> Can you give one good reason for removal of TARGETPATH?
>>
>> Thanks, Lyndon
>>
>> “Doron Holan” >> mailto:xxxxx
>> mailto:xxxxx>> mailto:xxxxx>> wrote in message
>>
>> news:xxxxx@ntdev…
>> Have you looked at BINPLACE? That will copy the resulting
>> bins in
>> whatever
>> dir you want independent of where the compiler generated the
>> binary.
>> Seems
>> to me you can just replace targetpath with it
>>
>> d
>>
>> Sent from my phone with no t9, all spilling mistakes are not
>> intentional.
>>
>> -----Original Message-----
>> From: Maxim S. Shatskih >> mailto:xxxxx
>> mailto:xxxxx>> mailto:xxxxx>>
>> Sent: Saturday, January 17, 2009 11:52 AM
>> To: Windows System Software Devs Interest List
>>
>> mailto:xxxxx>>
>> Subject: Re:[ntdev] WDK7 custom target path
>>
>>
>> >I noticed TARGETPATH (and TARGETPATHLIB) are no longer
>> supported
>> in WDK7.
>>
>> I second this.
>>
>> TARGETPATH is a very important feature which allows to build
>> lots of
>> EXE/DLL/SYS files using one “build” command, and then to
>> place all
>> of them
>> to a single directory for convinience.
>>
>> Also, I use LIB files for intermediate stages of BUILD, and
>> putting
>> them to
>> a single directory using TARGETPATH is a good idea again.
>>
>> People do really use TARGETPATH. It is a good thing, and too
>> bad it is
>> removed from Win7 DDK beta.
>>
>> –
>> Maxim S. Shatskih
>> Windows DDK MVP
>> xxxxx@storagecraft.com mailto:xxxxx
>> mailto:xxxxx>
>>
>> http://www.storagecraft.com http:</http:>
>>
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> For our schedule of WDF, WDM, debugging and other seminars
>> visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>>
>>
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> For our schedule of WDF, WDM, debugging and other seminars
>> visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>>
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>>
>> — NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging
>> and other seminars visit: http://www.osr.com/seminars To unsubscribe,
>> visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx>

[J_J_Farrell]

xxxxx@microsoft.com wrote:

Hi guys,

TARGETPATH (and TARGETPATHLIB) were deprecated in WDK beta because of Win7 changes in build.exe. I am sorry the documentation is a little bit late, but I can ensure you the update will be there soon.

I would like to make sure we understand the user scenarious that you addrees which were hit by this change so we consider them timely.

Daniel: about the custom tharget path - what do you mean by choosing a custom output dir? Is this the TARGETPATH that you think about? I see Max addressed this issue too. Or is it a complitely new path, not relative to source path?

So far TARGETPATH enabled custom OBJ_PATH directories to be set. For example:

Source code in: c:\WinDDK\base\abc\project
TARGETPATH set to: base\abc\project$O
Output will result in: c:\WinDDK\base\abc\project\objfre\i386

Let’s start the discussion from here and thanks for the valuabl? feedback!

Tanya

It seems extreme to go from “You must have TARGETPATH in your sources
file.” in one release of the WDK to “TARGETPATH is no longer allowed.
Remove it.” in the next. Wouldn’t it be possible (at least) to check for
it being set to “obj” as instructed for “almost all cases”, and ignore
it in that case?

jjf

[Tanya_Radeva]

I would agree with you that the WDK Documentation hasn’t been updated for a long time in regard to already existing macros and environment variables. TARGETPATH is not a must.

Thanks for the constructive feedback!