BUG: Visual Workbench Does Not Use .LIB Files as Dependents |
Q116485
1.00 1.50 WINDOWS kbtool kbbuglist ---------------------------------------------------------------------- The information in this article applies to: - The Visual Workbench included with: Microsoft Visual C++ for Windows, versions 1.0 and 1.5 ---------------------------------------------------------------------- SYMPTOMS ======== The Microsoft Visual Workbench creates project (.MAK) files based on the individual files added to the project. These project files include dependencies of the target file (.EXE, DLL, and so forth). If a dependency file is modified and its time stamp is later then the target file, the Visual Workbench should rebuild the target. Under the following conditions, the rebuild does not occur when it should: - The makefile is generated by Visual C++ and has been opened as an external makefile in the Visual Workbench. -or- - The same makefile is built using the external utility, NMAKE.EXE, from the MS-DOS prompt. -or- - The newly modified file is a .LIB file that is specified in the list of the project files by choosing Edit from the Project menu. Under the above circumstances, choosing to build the project does not cause the project to relink even though a library file has been modified. However, if the same makefile is opened as an internal makefile in the Visual Workbench and the Build option is chosen from the Project menu, the project is linked again as it should be because a .LIB file has been modified. CAUSE ===== If a library file is added to the project list of files rather than being added as a linker option, the Visual Workbench adds the library to the makefile, but the library is not set as a dependency of the project's (.EXE, DLL, and so forth) target file. The make engine used by the Visual Workbench for internal makefiles is not the same as the NMAKE.EXE utility. (The NMAKE.EXE utility is invoked for external makefiles by the Visual Workbench.) RESOLUTION ========== There are two possible workarounds to this problem: - If the .LIB file is not "code complete", add the .OBJ files that make up the library file to the project's list of files by using the Edit option on the Project menu instead of the .LIB file. -or- - Edit the makefile using the Visual Workbench or any other editor. Add the $(LIBS_EXT) macro to the $(PROJECT).EXE dependency block, which causes NMAKE to use the library as a dependency. The Visual Workbench accepts this minor change to the makefile. However, a shortcoming to this method is that the change disappears when you choose Scan All Dependencies from the Project menu. An example of the dependency line is shown below: $(PROJ).EXE:: TEST.OBJ $(OBJS_EXT) $(DEFFILE) Adding the library dependency results in the above line being changed to the following: $(PROJ).EXE:: TEST.OBJ $(OBJS_EXT) $(DEFFILE) $(LIBS_EXT) STATUS ====== Microsoft has confirmed this to be a bug with the Visual Workbench, versions 1.0 and 1.5. We are researching the problem and will post new information here in the Microsoft Knowledge Base as it becomes available. This is not a problem with either Visual C++ 32-bit Edition. Additional reference words: 1.00 1.50 KBCategory: kbtool kbbuglist KBSubcategory: VWBIss
Keywords : kb16bitonly
Issue type :
Technology :
Last Reviewed: December 22, 1999 |
