c++-Sogou C++ Workflow-Windows平台编译过程记录

原创地址：

https://blog.csdn.net/y281252548/article/details/114867880

 

changelog
2021年1月19日 继续尝试编译并运行实例程序
2021年1月18日 初步编译运行程序，编译出错
下载代码eatcosmos/workflow: C++ Parallel Computing and Asynchronous Networking Engine切换到Windows分支，因为这里是用Windows开发的。

参考[优秀开源项目C++高性能服务器引擎sogou/workflow学习笔记1-环境配置篇_AJIOY的专栏-CSDN博客

下载cmake3 Download | CMake安装，其中把camke加到系统环境变量

然后启动camke客户端，configure、generate报了一堆错误，不知道什么原因，估计是Windows分支没有配置好Windows编译环境。这怎么办呢？看了一堆莫名其妙的红色报错。

程序其实模块化的，假设整个系统只有一个模块，那么所有源文件都会有一个依赖网络，那么cmake的作用就是说明这个依赖网络，所以需要理解下cmake的工作原理，然后再读下项目的cmake配置看看是怎么回事。

磨刀不误砍柴工，不磨砍一次放弃一次，所以这次实践下 CMake 入门实战 | HaHack，总算把这个实践了下，感觉学习真是个无底洞啊，其实学习不应该学一个东西，而应该用一个东西。如果你想把cmake彻底弄懂，这个想法是要不得的，世上本没有cmake，皆因问题而生，无目标而学cmake，就属于浪费时间了。

我大概理解cmake了，所以可以使用cmake的客户端了：

说实话，上面下方两个绿色圆圈里是一堆visual studio的相关参数，不懂。其中CMAKE_INSTALL_PREFIX目录还是很有意思的，可以发现安装在C:\Program Files (x86)\workflow下面，这么一来的话，其实workflow的形式就很清楚，就是一个和qq类似的软件程序罢了，当然这个程序有好几个功能模块组成，也行是好几个exe文件。

接下来就是Generate，然后会在build里面生成项目工程了：

比如编译 util 工程，得到 D:\git\yq-sdk\sdk_workflow_windows\build\util\util.dir\RelWithDebInfo\util.lib

新增两个头文件路径

D:\git\yq-sdk\sdk_workflow_windows\src\kernel_win;D:\git\yq-sdk\sdk_workflow_windows\src;

然后编译 server 工程，然后他缺少的头文件就更多了，每次都是编译一次添加一次，然后我就发现，其实这些需要的头文件其实都在CMakeLists.txt里说过了：

使用正则表达式对这些头文件进行处理，最后得到下面的头文件路径，加入到配置里，然后server就编译成功了，得到一个链接库server.lib。

..\..\src\;..\..\src\kernel_win;..\..\src\algorithm;..\..\src\protocol;..\..\src\server;..\..\src\client;..\..\src\manager;..\..\src\util;..\..\src\factory;

其他项目依葫芦画瓢，关键就是补全头文件路径，然后依次编译成功链接库项目

util server protocol manager kernel factory client algorithm

单独编译完这些项目后，按道理应该不需要再编译Project项目了，还不清楚有什么区别。

这10个链接库模块编译成功后，就是编译ALL_BUILD项目->全部重新生成: 成功 11 个，失败 0 个，跳过 0 个

最后是INSTALL项目->提示没权限

使用管理员打开可以了，但是又出现了新的状况了

所以我就把ALL_BUILD里面的workflow直接移除，这次INSTALL编译成功了，但是按照目录都是空的：

然后在GitHub提问了 https://github.com/sogou/workflow/issues/170#issuecomment-762588413，作者很快就回复了，按照回复，安装Win32/Win64 OpenSSL Installer for Windows - Shining Light Productions，下载Win32OpenSSL-1_1_1i.exe，把C:\Program Files (x86)\OpenSSL-Win32\bin加入到环境变量。

还使用cmake图形界面Configure，作用和cmake -B build .一样的，把build下的东西都删除，还是命令行吧，命令的问题就是默认选的vs2019，所以还是用的图形界面：

这次sln的名字时workflow.sln

这次可以了，那么直接编译INSTALL这个项目吧，全部成功了：

那么说明问题就出在openssl的安装上，之前时自动搜的其他项目的openssl，估计很不全，所以没成功。

感觉workflow的项目比opencv、ffmpeg都清晰太多，关键是几乎没依赖，而且适配Windows平台。

运行示例代码

依然使用管理员运行vs2017

运行wget试下

小结
好了，至此编译和测试就完成了，可以发现因为workflow几乎不依赖第三方库，加上代码目录结构清晰，所以编译非常容易，反之如果依赖第三方库会导致连锁的版本依赖，甚至对vs版本也会有要求，而现在编译就很流畅，最后生成的文件路径也十分清晰，就一个workflow.lib。

openssl要单独下载，这个很重要。

workflow项目由多个模块平行组成，分别生成链接库，最后合并为workflow.lib链接库。

在这个基础上再开发exe程序，只需要调用workflow.lib即可。

参考资料
2019年，抛弃 CMake，用 Bazel / Buck 来构建大型项目吧 - 知乎

补充
Editing workflow/about-build-on-windows.md at windows-build · dengjunplusplus/workflow

# Windows下编译

安装OpenSSL
Windows下安装OpenSSL库包括以下几种方式
下载源码自行编译
下载二进制文件或安装包
通过Chocolatey安装
通过vcpkg安装
下载源码自行编译
可以去官网或者GitHub仓库进行代码下载，编译过程参见源码中的编译文档

openssl官网
github仓库
下载二进制文件或安装包
请自行通过搜索引擎进行搜索，将文件解压到特定目录，或者运行安装包
二进制下载

通过Chocolatey安装
Chocolatey是一个 Windows下的包管理器，类似于 Linux 下的 apt-get或 yum，可以方便的进行软件包的安装，Chocolatey的安装参考Chocolatey官网
安装完Chocolatey后，执行下面的命令，即可安装OpenSSL

choco install openssl
1
通过vcpkg安装
vcpkg是一个Windows下的C++包管理工具，它极大地简化了第三方库的配置与安装，vcpkg的安装请参考微软官方文档VCPKG官方文档
安装完vcpkg后，执行下面的命令，即可安装OpenSSL

vcpkg install openssl
1
编译workflow库
通过源码编译或者下载二进制进行openssl安装的，在编译过程中可以通过指定OPENSSL_ROOT_DIR的方式进行编译，在workflow根目录下执行下面的命令

cmake -B [build directory] -S . -DOPENSSL_ROOT_DIR=[openssl directory]
1
通过安装包安装或者通过Chocolatey安装openssl的，无需指定openssl的路径，在workflow根目录下执行下面的命令

cmake -B [build directory] -S .
1
通过vcpkg安装openssl的，需要指定CMAKE_TOOLCHAIN_FILE的路径

 cmake -B [build directory] -S . -DCMAKE_TOOLCHAIN_FILE=[vcpkg.cmake directory]
1
[openssl directory]: openssl目录，请自行替换

[build directory] : 构建目录，一般使用build目录

[vcpkg.cmake directory] : 一般为vcpkg根目录\scripts\buildsystems\vcpkg.cmake

执行完成后，在[build directory]下会生成workflow.sln，可以用VS打开进行编译，或执行cmake命令进行编译

cmake --build [build directory]
————————————————
版权声明：本文为CSDN博主「eatcosmos」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/dzxxbj/article/details/112803108