#NMAKE problem
6 messages in this thread
I having a problem getting objects to build in my makefile. The first one in
the list builds, but all others are not. What's strange is that it seems that
NMAKE realizes the target is out of date, because when I run nmake with:
nmake /d
I get the following output:
Microsoft (R) Program Maintenance Utility Version 1.12.0013
Copyright (c) Microsoft Corp 1988-90. All rights reserved.
X4WUTIL.c Thu Jul 29 14:49:18 1993
X4WUTIL.h Thu Jul 29 14:47:26 1993
X4WUTIL.obj target does not exist
cl386 -c -W3 -G3 -D_X86_=1 -DWIN32 -D_MT -D_DLL -Zi -Od X4WUTIL.c
Microsoft (R) C Optimizing Compiler Version 0.00.3043d
Copyright (c) Microsoft Corp 1984-1993. All rights reserved.
X4WUTIL.c
getvers.c Thu Jul 29 14:50:42 1993
X4WUTIL.h Thu Jul 29 14:47:26 1993
getvers.obj target does not exist
X4WUTIL.def Fri Feb 05 18:20:42 1993
X4WUTIL.rc Fri Jul 30 17:13:46 1993
X4WUTIL.res target does not exist
echo #define VER_PRODUCTVERSION_STR "0.0.0.0\0" >bldnum.h
echo #define VER_PRODUCTVERSION 0,0,0,0 >>bldnum.h
echo #define VER_FILEVERSION_STR "1.0.0.0\0" >>bldnum.h
echo #define VER_FILEVERSION 1,0,0,0 >>bldnum.h
rc -DWIN32 -r -fo X4WUTIL.res X4WUTIL.rc
del bldnum.h
X4WUTIL.res Tue Aug 03 15:23:28 1993
X4WUTIL.rbj target does not exist
cvtres -i386 X4WUTIL.res -o X4WUTIL.rbj
Reading X4WUTIL.res
Writing X4WUTIL.rbj
X4WUTIL.DLL target does not exist
lib32 -machine:i386 -def:X4WUTIL.def -out:X4WUTIL.lib
Microsoft(R) Windows NT Librarian Version 2.29
(C) 1989-1992 Microsoft Corp. All rights reserved.
X4WUTIL.def – line #5() : warning 517: keyword EXETYPE will be ignored
X4WUTIL.def – line #7() : warning 517: keyword STUB will be ignored
Creating library X4WUTIL.lib and object X4WUTIL.exp from X4WUTIL.def
definition file.
link32 -debug:full -debugtype:cv @prog.lnk
Microsoft(R) Windows NT Linker Version 2.29
(C) 1989-1992 Microsoft Corp. All rights reserved.
-base:0x1c000000
-dll
-entry:LibMain@12
-out:X4WUTIL.dll
X4WUTIL.exp
X4WUTIL.obj getvers.obj
LINK32() : error 104: Can't open file getvers.obj
Extended Error: No such file or directory
NMAKE : fatal error U1077: 'C:\winnt\system32\cmd.exe' : return code '4'
Stop.
*****************************************************************
You can see that the target getvers.obj does not exist, but it is also not
built.
A piece of my makefile is below:
# Link command uses inline file (no filename specified) & macro substitution
$(PROG).DLL : $(MYOBJS) $(MYLIBS) $(PROG).def $(PROG).res $(PROG).rbj
# Run IMPLIB to create the import library for the DLL
$(implib) -machine:$(CPU) -def:$(PROG).def -out:$(PROG).lib
# Link DLL
$(link) $(LFLAGS) @<<prog.lnk
-base:0x1c000000
There is 1 Reply.
Jim,
> I'm having a problem getting object to build in my makefile. The first one
in the list builds, but all other are not.
This is the way NMAKE works, it only builds the first target. This is why we
use pseudotargets in makefiles, to ensure that everything is built properly.
Check out the topic "pseudotarget" in the NMAKE documentation for more
details. Also, our sample makefiles use this technique, so they are a good
reference as well.
Sincerely,
Julie Solon
Microsoft Developer Support
There is 1 Reply.
Perhaps I didn't explain this properly. When you have the following:
.c.obj:
$(cc) $(cflags) $(cdebug) $<
file1.obj: file1.c
file2.obj: file2.c
file3.obj: file3.c
target.exe: file1.obj file2.obj file3.obj
link ….
This should build all three object files if they are either out of date or
non-existent. In my case, when building a 32-bit DLL, I can only get file1 to
build. I don't understand this behavior.
–Jim.
There is 1 Reply.
Jim,
> Perhaps I didn't explain this properly.
Yes, you did. The first target is file1.obj. That is all it builds.
Try this instead (note use of pseudotarget "all").
# makefile
!include <ntwin32.mak>
all: target.exe
.c.obj:
$(cc) $(cflags) $(cdebug) $<
file1.obj: file1.c
file2.obj: file2.c
file3.obj: file3.c
target.exe: file1.obj file2.obj file3.obj
link ….
There is 1 Reply.
I've been using the pseudotarget all from the beginning. The strange thing is
that this only happens with DLLs. There's nothing special about .EXEs are far
as NMAKE is concerned, is there?
There is 1 Reply.
Jim,
> The strange thing is that this only happens with DLLs.
I can get this to work with DLLs as well.
> There's nothing special about .EXEs as far as NMAKE is concerned, is there?
Nothing that I can think of. Can you show me your makefile?
Julie