windows下c/c++构建总结

windows下c/c++的开发可以用vs和mingw，有时候也会考虑跨平台方案，本文总结一下使用情况以及对c++构建生态的一种推断

 

mingw

1.mingw是模拟linux构建一套gcc的开发环境，形成一套linux的gcc开发风格，提供了一些linux风格的标准库。但是有一些也不完善，比如socket的开发还是用windows的库跟linux有点不一样。但是接口类似通过宏也能解决
2.对于c和c++的学习，使用mingw是可以的，而且一些小的项目或者独立的项目mingw也都可以，比如我上次做的管道工都挺好。而且mingw上边还有一个mysys这个东西。mysys提供了一个库的管理工具，类似c++版本的maven和npm。常见的包也都有，比如paho、sqlite、opencv这些。但是一些不常见的包就没有了。使用这些包的时候有时候会有问题，就是这些包只能在mingw下用，因为微软太强。免不了会使用msvc，这个时候就比较尴尬

3.vscode和mingw结合的比较好，当然vscode跟别的开发环境集合也都差不多。但是互联网上的文章在配置vscode的时候基本都是基于mingw来配置的，说明大家在vscode中开发c++的时候大部分都用mingw。对于使用vs的人来说，肯定是用msvc了，他们也不会关心mingw和vscode

cmake

1.我使用c++的初心，其实是因为我一直以来断断续续的研究opencv、caffe、tensorflow这些，我发现他们这些东西都是用c++写的。而且都是用的cmake而不是make

从这些项目可以推断他们的开发习惯也就是c++生态的开发习惯

2.们的开发场景应该是以linux开发为主，所以他们的日常开发应该在linux上的。也就是他们的项目构建第一视角是linux而不是windows。但是低于opencv、caffe、paho.c这些项目，他们都提供了windows构建的支持。而且他们统一的选择是cmake生成msvc这个工具链，而不是mingw这个工具链

3.分析他们的原因应该有两点，首先是对于要构建c++的开发者而言，在windows上肯定都安装了免费的vs，但是未必都安装了mingw，非要开发安装mingw至少有一半的开发者要骂娘。其次，msvc和vs毕竟是工业级的开发环境太强了，mingw还是类似一个发烧友的小玩意，如果是opencv这种重量级的库就没有必要再跟mingw折腾了。

4.基于以上几点基本得出结论，工业级的开发都是使用cmake这种方式来进行跨平台的项目构建。下面再说一下他们的具体方式

5.cmake构建的时候，使用cmake .. -G "xxx",这个G是generator的意思就是你使用哪个Toolchain、cmake可以生成几十种工具链，codeblock、eclipse cdt、vs的sln、nmake、makefile、minggw等应有尽有。但是上面的这几个项目他们一般不会选择mingw工具链，他们一般选择的工具链有：nmake或者默认的vs的sln，构建的时候cmake ..之后直接nmake或者cmake --build就可以了，但是他们都是支持生成vs的sln的，你可以自己打开vs的sln自己手工编译

6.当你执行nmake install或者cmake --build . --target install 的时候，库的安装一般在C:/Program Files (x86)/Eclipse Paho C/目录下，如果你开发的项目也使用cmake，那么你通过find_package就可以直接引用这些头文件和库了。
执行nmake install的时候要在vs提供的一个特殊命令行(如：Developer Command Prompot for VS 2019，以administrator身份打开)里执行

因为库都是cmake生成的，所以我们开发的项目使用cmake来调用这些库及比较方便，所以我们开发的时候也首选cmake

7.如果使用cmake作为构建工具，那么我们开发的时候就先开发CMakeLists.txt,然后再使用cmake生成sln，就可以在vs中开发了。对于这种情况和vscode结合我还没怎么研究，不知道情况怎么样
vs也支持不用sln构建项目而是使用cmake，但是不稳定，我没试成功老是报错

8.如果我们开发的项目，使用cmake生成mingw的makefile，然后在vscode下开发，这种模式的可行性。因为我们一来的第三方包是cmake生成msvc构建的，使用mingw的makefile方式一般都不支持，在这种情况下我们开发的项目在引用这些库的时候会出现不能找到库的情况，可能是我技术不行，以后会持续的研究