problem with the !IF directive in SOURCES file

all,

I have been trying to add a special #ifdef flag for my checked builds,
but SOURCES seems to always use the appended version and hence both
release and chk binaries are identical in that respect.

C_DEFINES=$(C_DEFINES) -DUNICODE -DK_MODE
!IF (“$(DDKBUILDENV)”==“chk”)
C_DEFINES=$(C_DEFINES) -D_DUMP_STUFF
!ELSE
C_DEFINES=$(C_DEFINES)
!ENDIF

-D_DUMP_STUFF seems to be always included, I searched the archives and
got some posts, but none of them seemed to resolve the issue.

can anyone suggest something?

thanks

ami awbadhho

Ami Awbadhho wrote:

all,

I have been trying to add a special #ifdef flag for my checked builds,
but SOURCES seems to always use the appended version and hence both
release and chk binaries are identical in that respect.

C_DEFINES=$(C_DEFINES) -DUNICODE -DK_MODE
!IF (“$(DDKBUILDENV)”==“chk”)
C_DEFINES=$(C_DEFINES) -D_DUMP_STUFF
!ELSE
C_DEFINES=$(C_DEFINES)
!ENDIF

-D_DUMP_STUFF seems to be always included, I searched the archives and
got some posts, but none of them seemed to resolve the issue.

There’s no reason that shouldn’t work, although the whole !ELSE clause
is silly and can be removed.

However, none of that should be necessary. The build system already
defines DBG for checked builds. So:

#ifdef DBG
#define _DUMP_STUFF
#endif


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Tim,

just to be clear, I have defined this !IF in the ‘sources’ file,
though in the help section @ MSDN there is no !IF defned for sources.
I did so, because in an earlier post here at OSR the OP seems to be
trying to do so (without success)
https://www.osronline.com/ShowThread.cfm?link=144905

Am I supposed to define this conditional in the custom make file
instead of the sources file?

thanks

Awbadhho

On Thu, Oct 20, 2011 at 10:59 PM, Tim Roberts wrote:
> Ami Awbadhho wrote:
>> all,
>>
>> I have been trying to add a special #ifdef flag for my checked builds,
>> but SOURCES seems to always use the appended version and hence both
>> release and chk binaries are identical in that respect.
>>
>> C_DEFINES=$(C_DEFINES) -DUNICODE ?-DK_MODE
>> !IF (“$(DDKBUILDENV)”==“chk”)
>> C_DEFINES=$(C_DEFINES) -D_DUMP_STUFF
>> !ELSE
>> C_DEFINES=$(C_DEFINES)
>> !ENDIF
>>
>> -D_DUMP_STUFF seems to be always included, I searched the archives and
>> got some posts, but none of them seemed to resolve the issue.
>
> There’s no reason that shouldn’t work, although the whole !ELSE clause
> is silly and can be removed.
>
> However, none of that should be necessary. ?The build system already
> defines DBG for checked builds. ?So:
>
> ? ?#ifdef DBG
> ? ?#define _DUMP_STUFF
> ? ?#endif
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> 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
>

Ami Awbadhho wrote:

just to be clear, I have defined this !IF in the ‘sources’ file,
though in the help section @ MSDN there is no !IF defned for sources.
I did so, because in an earlier post here at OSR the OP seems to be
trying to do so (without success)
https://www.osronline.com/ShowThread.cfm?link=144905

“Sources” is scanned by build.exe so it can build the dependency tree.
After that, build simply invokes nmake. So, “sources” is really just a
makefile. Nmake invokes your makefile, which !includes makefile.new,
which eventually !includes sources. Thus, anything nmake accepts will work.

(You can demonstrate this yourself. After you have run “build” once,
you can simply run “nmake”.)

Am I supposed to define this conditional in the custom make file
instead of the sources file?

Not sure what you mean. The code I posted would go into a C include
file. As I said, the build environment already #defines the C
preprocessor symbol DBG for checked builds. You don’t have to define
your own.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

> “Sources” is scanned by build.exe so it can build the dependency tree.

After that, build simply invokes nmake. So, “sources” is really just a
makefile. Nmake invokes your makefile, which !includes makefile.new,
which eventually !includes sources. Thus, anything nmake accepts will work.

BTW - what entity makes the dependency list of on what .h files the .c file depends?

This dependency surely works for BUILD, but I don’t know where the tree is stored and what agent generates the tree.

I only know that CL can print out all header file names (in some mode).


Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

Maxim S. Shatskih wrote:

> “Sources” is scanned by build.exe so it can build the dependency tree.
> After that, build simply invokes nmake. So, “sources” is really just a
> makefile. Nmake invokes your makefile, which !includes makefile.new,
> which eventually !includes sources. Thus, anything nmake accepts will work.
BTW - what entity makes the dependency list of on what .h files the .c file depends?

This dependency surely works for BUILD, but I don’t know where the tree is stored and what agent generates the tree.

Build.exe creates it, and it gets cached in “build.dat” in the root of
your DDK tree.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

thanks all for trying to help.

I am replying to all your queries in one email…

Tim,

Am I supposed to define this conditional in the custom make file
instead of the sources file?

Not sure what you mean. The code I posted would go into a C include
file. As I said, the build environment already #defines the C
preprocessor symbol DBG for checked builds. You don’t have to define
your own.

[AA] Yes, I understood your code, but I wanted to put it in the
‘sources’ file and not modify each source C file individually. Or to
put it in a header file, where ther chances of one of the source files
not including the header will cause issues.

On Mon, Oct 24, 2011 at 11:41 PM, Tim Roberts wrote:
> Maxim S. Shatskih wrote:
>>> “Sources” is scanned by build.exe so it can build the dependency tree.
>>> After that, build simply invokes nmake. ?So, “sources” is really just a
>>> makefile. ?Nmake invokes your makefile, which !includes makefile.new,
>>> which eventually !includes sources. ?Thus, anything nmake accepts will work.
>> BTW - what entity makes the dependency list of on what .h files the .c file depends?
>>
>> This dependency surely works for BUILD, but I don’t know where the tree is stored and what agent generates the tree.
>
> Build.exe creates it, and it gets cached in “build.dat” in the root of
> your DDK tree.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> 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
>

I haven’t really followed thi thread closely, but sources is fairly
dysfunctional and frustrating.

Usually I’ve found that putting stuff in sources.Inc (or whatever) and
including it in sources will generally work in a fairly predictable way:

For example:
Sources:
Chksrcs = chk.c
!include sources.inc

Sources.Inc:

Sources = $(chksrcs) \


Not at all convenient, but it does usually work.

Mm
On Oct 25, 2011 12:08 AM, “Ami Awbadhho” wrote:

> thanks all for trying to help.
>
> I am replying to all your queries in one email…
>
>
> Tim,
>
> > Am I supposed to define this conditional in the custom make file
> > instead of the sources file?
>
>
> Not sure what you mean. The code I posted would go into a C include
> file. As I said, the build environment already #defines the C
> preprocessor symbol DBG for checked builds. You don’t have to define
> your own.
>
>
> [AA] Yes, I understood your code, but I wanted to put it in the
> ‘sources’ file and not modify each source C file individually. Or to
> put it in a header file, where ther chances of one of the source files
> not including the header will cause issues.
>
>
> On Mon, Oct 24, 2011 at 11:41 PM, Tim Roberts wrote:
> > Maxim S. Shatskih wrote:
> >>> “Sources” is scanned by build.exe so it can build the dependency tree.
> >>> After that, build simply invokes nmake. So, “sources” is really just a
> >>> makefile. Nmake invokes your makefile, which !includes makefile.new,
> >>> which eventually !includes sources. Thus, anything nmake accepts will
> work.
> >> BTW - what entity makes the dependency list of on what .h files the .c
> file depends
?
> >>
> >> This dependency surely works for BUILD, but I don’t know where the tree
> is stored and what agent generates the tree.
> >
> > Build.exe creates it, and it gets cached in “build.dat” in the root of
> > your DDK tree.
> >
> > –
> > Tim Roberts, xxxxx@probo.com
> > Providenza & Boekelheide, Inc.
> >
> >
> > —
> > 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
>