CSDN博客

img imquestion

关于 VC 编译的猜想与试验

发表于2003/5/8 14:14:00  1729人阅读

关于 VC 编译的猜想与试验

作者: JIURL

                 主页: http://jiurl.yeah.net/

   日期: 2003-5-4


    今天在看从一个从Console程序中导出的makefile文件时,产生了一些想法。为了验证这些想法,于是做了些试验。我的环境是 Win2K ,VC6。

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

0 0

相关博文

我的热门文章

img
取 消
img