此文一定程度上说明了VC IDE的构造机理。很有趣的实验。

 

首先简单介绍一下程序是如何编译链接的。程序写好之后，我们进行编译和链接来产生可执行程序。这时候，编译器为了完成编译和链接，需要知道很多信 息。比如要编译的文件是哪一个，使用哪些编译选项进行编译，编译好之后输出到哪里，输出文件叫什么名字等等。makefile 就是被vc使用保存这些信息的方法之一，编译时程序nmake根据makefile中的信息，在用相应选项执行编译，用相应执行链接，最后生成可执行文件。vc的编译程序是CL.EXE，链接程序是LINK.EXE。关于本文所提到的vc编译链接用的程序都在目录 "$VCInstDir/Microsoft Visual Studio/VC98/Bin" 下。

 

整个过程如下。

 

在我看这个console程序的makefile的时候，突然怀疑vc6中，console，sdk，mfc等的编译也是通过执行外部的 nmake.exe来完成的。如果真是我猜的这样的话，如果我在vc的集成环境中选择rebuild all 进行编译链接的话，vc就会执行nmake.exe文件，那么nmake.exe这个文件必须存在，否则的话编译就会失败。于是，我将 nmake.exe 这个文件改了个名字。来测试，vc6的console，sdk，mfc程序是否是调用nmake来完成编译的。

 

结果很失望，没有了nmake.exe，这个console程序一样可以编译。这说明了，vc6并不是通过执行nmake来进行编译的。可能是调用内部的某些函数，来处理各种编译的参数和路径，再分别调用编译程序和链接程序来完成编译。不过再想想也是，连makefile文件都没有。不会是通过 nmake 来指导编译的。

 

那么使用makefile的程序（叫project更准确）的情况又如何呢？于是我又找了一个使用makefile的程序来试，我找的是msdn附带例子中的ping，这个是使用makefile的。这一次，如果没有nmake.exe，就无法进行编译。会报如下错误'NMAKE' 不是内部或外部命令，也不是可运行的程序或批处理文件。

 

Error executing d:winntsystem32cmd.exe.

 

由此可见，使用makefile的程序，确实是通过nmake.exe分析makefile中的内容，来指导编译的。

 

总结一下，用VC new->project 中的 Win32 Console Application （console)，Win32 Application (sdk)，MFC AppWizard (mfc) ，这样建的程序，编译不通过nmake。而使用 Makefile 的编译会通过 nmake 处理相应的makefile文件，来进行编译。顺便说一句，没有makefile的工程，他们的编译信息，编译选项放在了哪里呢？这个是我本身就知道的， 他们放在工程目录下的dsp文件中，用编辑器，比如记事本，打开dsp文件就可以看到。也可以打开dsw文件看看。

 

最后我又做了这样两个试验，

 

将CL.EXE改名。结果编译出错。错误如下。

 

Compiling... Error spawning cl.exe

 

一定程度可以说明了，编译程序是CL.EXE，VC集成环境下的编译，也是用一定的编译选项调用CL.EXE来完成的。

 

将LINK.EXE改名。结果链接出错。错误如下。

 

Linking... Error spawning link.exe

 

一定程度可以说明了，链接程序是LINK.EXE，VC集成环境下的链接，也是用一定的链接选项调用LINK.EXE来完成的。