windows平台，使用cl.exe /Zs /showIncludes选项输出头文件依赖
忙活了两周，在编译系统，一种变形的makefile里，增加了依赖生成。
一测试，
完整编译需要5分钟,280多cpp文件；
修改某个.h，影响130个cpp；更新这些cpp的依赖，13分钟。我的天。

原因是，cl.exe /MP 多进程，已经是非常快了。
/MP和/showIncludes不兼容，所以后者只能单进程执行，导致局部分析比整体编译还慢。

windows平台都是咋解决这问题的？ msbuild有头文件依赖检测吗，咋实现的？业界这问题最新进展?


拉我入坑的文章，
http://make.mad-scientist.net/papers/advanced-auto-dependency-generation/#tldr
https://stackoverflow.com/questions/946105/makedepend-equivalent-for-use-with-nmake
--
FROM 61.185.161.*

c++20 module
--
FROM 114.87.115.*

你那make_closure，能用不？
【 在 ziqin 的大作中提到: 】
: c++20 module
--
FROM 61.185.161.*

我在搞的是另一个make，qt这条道走通了也没办法融合，算了，
以后痛了，公司估计就花钱买Incredibuild了。

假设gnu的make叫amake，我的是bmake，流行的是CMake，微软的是nmake，qt的叫qmake，版上还有xmake……不归路，算了

语言、编译器、项目管理、build系统、包管理的多级系统问题。不可能清爽的。
够大的项目，估计都是堆起来精雕细琢，后来者只能用，不能改。
【 在 z16166 的大作中提到: 】
: Qt有个nmake clone，可以执行多个job
: https://wiki.qt.io/Jom
: 把分析依赖的操作搞一个nmake工程，用jom并发执行？
--
FROM 61.185.161.*

一般公司用个大公司的sdk，就像用了qt，就极大概率会用qmake。

老板忙上市呢，哪管这个。 部门领导能感受到就不错了，比如技术会议上多次听到反应编译慢，一次50分钟，1小时，估计就会花钱了
【 在 z16166 的大作中提到: 】
: 自己搞私有的make系统，要么大公司，要么蛋疼
: 这种事情老板不会痛，痛的只会是码农
:
--
FROM 61.185.161.*