lotus



previous page: 11.5: Other Errors
  
page up: Programming VCOMM FAQno next page

11.6: Makefiles and #defines




Description

This article is from the Programming VCOMM FAQ, by nelson@desktop.nsc.com (Taed Nelson) with numerous contributions by others.

11.6: Makefiles and #defines


This is somewhat out of the scope of VCOMM, but it is useful information
nonetheless.

11.6.1: Turning off optimization (Taed's way)


[Fixed in version 2.02 with the addition of the COPTFLAGS define.]

[Contributed by Taed Nelson (nelson@lan.nsc.com).]

To make debugging easier, I turn off all optimizations, and attempt (but fail)
to get more debugging information, by editing \VTD95\Include\MS9.MAK to the
following:

	CFLAGS          = -W2 -Zp -Gs -c -bzalign -Zl -D_X86_ -DIS_32 \
			  -DWANTVXDWRAPS -DVTOOLSD
	ASMFLAGS        = -DMASM6 -c -W2 -Cx -DCOFF -coff
 
	! if $(DEBUG) != 0
	CFLAGS          = $(CFLAGS) -Od -Oi -DDEBUG -Zi
	ASMFLAGS        = $(ASMFLAGS) -DDEBUG -Zi
	! else
	CFLAGS          = $(CFLAGS) -Ogaisb1
	ASMFLAGS        = $(ASMFLAGS)
	! endif

11.6.2: Turning off optimization (Michael's way)


[Fixed in version 2.02 with the addition of the COPTFLAGS define.]

[Contributed by Michael Grabelkovsky (michael@slink.co.il).]

All of us have had a problem when the debugger (ICE) shifts the lines of the
program. This is a recommendation improve the situation:

The next fragment is added to the project MAK file after the "!include
$(VTOOLSD)\..." statement:

! if $(DEBUG) == 1
CFLAGS = $(CFLAGS) -Od
! endif

If the macros such as VxDJmp and VxDCall are used, they will not work
correctly without optimization. The next pragma corrects the situation:

#pragma optimize( "gas", on ) // enable optimization
#pragma optimize( "gas", off ) // disable optimization

The last statements may be correctly used together with #ifdef DEBUG...
statement for the same goals.

11.6.3: Version resource


[Fixed in version 2.02.]

If you have a version resource file, such as <project>.vrc, it will be
overwritten by VtoolsD every time you do a build-all.

This can be avoided by editing the VtoolsD makefile. For example, in
\VTD95\Include\MS9VXD.MAK, you can comment out the following lines:

#$(VRCNAME): $(VTOOLSD)\include\default.vrc
# copy $(VTOOLSD)\include\default.vrc $(VRCNAME)

11.6.4: Dependencies


Remember that your project makefile does not have full dependencies, unless
you generate them by hand. For example, if you change a .H file, the
appropriate .C or .CPP file will not recompile.

This can be avoided by always doing a build-all (takes longer to compile),
generating the full makefile dependencies by hand (annoying to keep
up-to-date), or finding a PC version of the funky Unix tool MAKEDEPEND.

If anyone finds a PC version of MAKEDEPEND, please let the list know.
Surprisingly enough, it is not in the ever-dependable MKS Toolkit.

11.6.5: Assert versus ASSERT


[Fixed in version 2.03 with the addition of a global #define.]

If you have used the ASSERT macro in the past, then you are used to ASSERT.
The VtoolsD version is spelled as Assert. To make matters worse, ASSERT is
defined in MINIPORT.H as nothing!

To get around this, I commented the line out of MINIPORT.H, and added the
following to my project makefile:

XFLAGS = -DASSERT=Assert

11.6.6: DEBUG versus _DEBUG


Microsoft VC++ users are used to seeing the #define for _DEBUG. VtoolsD uses
DEBUG. (It may actually be useful to have different #defines for some
people.) This is a trivial change to \VTD95\Include\MS9.MAK:

CFLAGS = ... -DDEBUG -D_DEBUG ...
AFLAGS = ... -DDEBUG -D_DEBUG ...

11.6.7: Avoiding the dprintf() call


When not compiling with DEBUG, the dprintf() function is still called, but it
is just a stub which does nothing. The reason for this is that the C
pre-processor cannot handle macros with variable number of arguments.

To avoid this minimal overhead, many solutions have been proposed, but the one
suggested by David McCullough (davidm@stallion.oz.au) seems to be the best:

#ifdef DEBUG
#define DPRINTF dprintf
#else
#define DPRINTF 0 && (* (int (*)(...)) 0)
#endif

For the non-DEBUG case, it will first test the "0", which will never be TRUE,
and therfore it will never continue with the function call. A NULL function
pointer is used, instead of dprintf(), to avoid the function being linked in.
With optimizations on, the entire statement should not generate any code.
(Although the format strings may still exist after linking.)


 

Continue to:















TOP
previous page: 11.5: Other Errors
  
page up: Programming VCOMM FAQno next page