VS 的makefile工程

自从IDE 的出现简化了代码文件之间关联性管理后，就没多少愿意用makefile 管理工程的了。makefile 的语法规则也不复杂，加上后续的automake 让编写的东西又简化了不少，但是相比IDE 点一下build 的操作来说依然是没有可比性的。各个平台下的IDE 对工程文件的规则都不一样，想要工程跨平台唯一适合互通的也就只有makefile 了，想必这也是目前makefile 还依然活跃的重要理由之一吧。

微软的IDE 从VC 6 以后就越发的对makefile 不友好了，之前的导入导出操作在后续的VS 里都没了，估计总觉得GNU Make 不适合垄断吧，搞了个NMake 的标准，非但没GNU Make 灵活（嵌套层次支持少，不支持单字符变量）自个的VS 支持起来也不顺。

但凡免费的第三方库，大都只提供makefile 而不提供. vcproj, 搞得想在VS 里编个库用用还得自己组织一边，大工程搞起来甚为麻烦。笔者被反反复复的转工程折腾几次后，似乎找到了个救命稻草- VS 的 makefile project 。

这种工程并不能帮你简化编写 makefile 的过程，也不能帮你导出已有 vcproj 工程到一个 makefile 里， 它的目的很简单就是把符合NMake 规则的makefile 和代码文件拽到一个虚拟的文件夹里，方便习惯了用solution explorer(SE) 的人来修改管理这些东西，调用cl.exe 和link.exe 来执行makefile 的内容生成当前平台下的目标文件(exe|lib|dll) 。与其他工程不一样的是即便加到solution explorer 里，源文件并不会编译中间代码。

基于以上目的，该工程的Wizard 也很是简陋：

其实算得上有用的也是左边的3 个command line, 这里需要填写的是nmake xx ，xx 为makefile 里定义的某个目标，一般来说makefile 里都会有all 和clean 这2 个目标，rebuild 无非是把clean + all 放一起就行了。还得去掉默认的输出，要不和makefile 里的重复了。点击finish 以后就可以把工程里的所有文件按你的习惯加入到SE 中了，需要注意的一点是如果不想写太复杂的command, 需要保证makefile 文件的命名为makefile( 大小写均可) ，并放在该vcproj 文件同级目录。

从一个makefile 工程到vs 里的简化流程应该如下：

1 在源文件夹中顶级目录下makefile （一般每个子目录下都会有个makefile ）所在位置创建该工程vcproj.

2 按makefile 中的目标填写command line

3 把工程中需要修改或管理的文件按习惯加入到solution explorer 中

4 点击编译，如果失败就得按照output 的提示适当修改makefile ，常见的问题都是makefile 里有不符合nmake 规则或是编译标志设置的是gcc 环境的那些宏和变量等等。( 如果工程里有带.nmake 后缀的文件, 果断重命名替换原有的makefile)

- ------------------------------------------- ------------------------------------------- ------------------------------------------

这种工程的用法，其实跟命令行方式下，使用nmake是一模一样的。因为该工程并不会追踪makefile中任何文件的信息，对他来说，它的一切关心的便是MAKEFILE，所以MAKEFILE不变，他的一切行为也不会改变。

并且在工程中任何作出的修改，也不会修改MAKEFILE。

基本上，该工程存在的意义就变成了，仅仅作为一个文件浏览器的前端。就像windows自带的explorer一样。其他，它全不关心。

对一个第三方库的轻量级修改的话，还是有用的！