Maintaining a Library with NMAKE

This article has been archived. It is offered "as is" and will no longer be updated.
Summary
NMAKE provides several features that ease the process of maintaining alibrary by incrementally updating only the modules that change. Withthe $? special macro and macro substitutions, the process involvesonly one call to LIB (the library maintenance utility). The text belowpresents makefiles that illustrate this procedure.
More information
The sample makefiles below keep MYLIB.LIB up to date with respect tothe four object files listed in the OBJS macro. These object files canbe based on C or assembly language source files. You can extend thelist of source-file types the makefile supports by adding theappropriate inference rules to the description file.

Sample makefile 1 includes the following line to maintain the library:
   LIB MYLIB.LIB -+$(?: =-+);				
The $? macro expands to the list of all dependents that are out-of-date with respect to the target file. The "$(?: =-+)" part of thecommand-line is a macro substitution to be performed on the $? macro.This substitution instructs NMAKE expand $? to the list of out-of-datedependents, but then replace all spaces in the expanded list with thetwo-character pair "-+".

For example, assume that only MOD1.OBJ, MOD3.OBJ, and MOD4.OBJ areeach out-of-date with respect to MYLIB.LIB. The $? macro expands tothe following:
   MOD1.OBJ MOD3.OBJ MOD4.OBJ				
Therefore, $(?: =-+) actually causes the macro to be expanded withsubstitution as follows:
   MOD1.OBJ-+MOD3.OBJ-+MOD4.OBJ				
With the remainder of the command line included for reference, theNMAKE executes the following command line:
   LIB MYLIB.LIB -+MOD1.OBJ-+MOD3.OBJ-+MOD4.OBJ;				
Note that the first time you add a module to the library with thiscommand, LIB generates a "U4155: module not in library" warning toindicate that LIB is unable to replace a module because it is notfound in the library. You can ignore the warning because LIB simplyadds the module to the library.

This method works correctly as long as the OBJS macro does not containtoo many modules. If the macro expansion causes the command line toexceed the MS-DOS or OS/2 command-line length limit (128 or 255characters, respectively), the LIB call fails. If your librarycontains enough modules such that this may occur, then you should usethe NMAKE in-line file capability to generate a response file.

Sample makefile 2 below demonstrates the response file method. Themakefile creates a response file named MYLIB.LRF that contains thelines of the makefile between the double angle bracket (<<) tokens.The contents of the makefile reflect a macro substitution that is verysimilar to the method demonstrated above. The major difference is asfollows: an input line in the response file is required for each LIBprompt. Therefore, the macro substitution must place newlinecharacters into the file. The following command does this:
-+$(?: = &^-+);				
This command instructs NMAKE to expand the macro for out-of-datedependents by replacing each space with a space, and ampersand (&), anewline and a "-+" character pair. The caret (^) instructs NMAKE tointerpret the next character literally, to place the newline characterthat follows the caret into the macro. (Because you type ENTER toplace a newline character into the file, the end of the macrosubstitution must appear on the following line.)

Therefore, given the same scenario as above, if MOD1.OBJ, MOD3.OBJ,and MOD4.OBJ are out-of-date with respect to MYLIB.LIB, the $? macroexpands to the following:
   -+MOD1.OBJ &   -+MOD3.OBJ &   -+MOD4.OBJ;				
With this method, you can maintain any number of object files with onecall to LIB.

Note: NMAKE version 1.1 (provided with Microsoft C versions 6.0 and6.0a) does not expand the $? macro correctly unless the target-dependency line uses the multiple dependency operator, a double colon(::). To work around this problem, modify the makefile to specify adouble colon instead of a single colon for the dependency thatinvolves the library.

For more information on macro substitution or in-line files, pleaserefer to the NMAKE documentation or online help provided with yourcompiler. For more information on response files, please refer to theLIB or LINK documentation or online help.

Sample NMAKE Makefile 1

# The OBJS macro lists the object files to keep in the library.OBJS = MOD1.OBJ MOD2.OBJ MOD3.OBJ MOD4.OBJ.c.obj:    cl /c $?.asm.obj:    masm $?;mylib.lib : $(OBJS)    LIB MYLIB.LIB -+$(?: =-+);				

Sample NMAKE Makefile 2

# The OBJS macro lists the object files to keep in the library.OBJS = MOD1.OBJ MOD2.OBJ MOD3.OBJ MOD4.OBJ.c.obj:    cl /c $?.asm.obj:    masm $?;mylib.lib : $(OBJS)    LIB $*.LIB @<<MYLIB.LRF-+$(?: = &^-+);<<KEEP# Note: The word "KEEP" after the << token is optional; it prevents# NMAKE from deleting the in-line file that it creates. This also# allows you to view MYLIB.LRF (after you finish running NMAKE) if you# want to verify what NMAKE writes into the response file. By default,# NMAKE deletes all in-line files before it terminates.				
kbinf 1.10 1.20 1.30 1.40 no32bit
Properties

Article ID: 71422 - Last Review: 01/11/2015 00:49:10 - Revision: 3.0

  • kbnosurvey kbarchive kb16bitonly KB71422
Feedback