回帖：吐槽一下OpenSSL的构建系统。
OpenSSL从我接触开始到现在一直使用一个基于Perl的自制构建系统，而不是使用更通用的autoconf和CMake。在OpenSSL 1.1发布的时候他们甚至对这个构建系统进行了一次重构，但是依然使用Perl而不是CMake等更加通用的工具。
根据OpenSSL的FAQ上的说法，OpenSSL支持的平台广泛。autoconf和CMake均不能满足OpenSSL的要求。
不过说实话，我真的想不到CMake不能满足OpenSSL的理由。这货是现在第一大跨平台构建工具，对各种平台都有广泛的支持，只要有平台描述文件，有工具链，CMake就可以生成对应的Makefile了。平台描述文件基本上还都是构建者自己写或者工具链提供，工程本身不负责平台描述文件，给OpenSSL维护者省了不少活。CMake少数几个小缺点就是冷门平台非交叉构建的鸡生蛋问题，和本身需要C++支持，除此之外相当完美。
不使用autoconf倒是容易理解，因为这玩意的windows支持非常不友好。autoconf这个玩意出自GNU，而GNU这帮人对Windows普遍没有好感，所以Windows支持看起来根本没有好好做。如果要用MSVC的话，需要Cygwin或者msys2套件，并且进行很复杂的配置，相当折磨。
他自己的构建系统到现在依旧有很多问题。
1. 对于一个平台，仅通过Makefile模版支持一种构建工具，并且***不***接受任何其他构建工具相关的内容，哪怕这个其他构建工具是原构建工具的原位替代品。
一个典型的例子就是nmake和jom，明明添加一个编译器flag（/FS）就可以有限支持jom，可以使用多核CPU多进程编译加快构建速度，虽然可能因为依赖关系的原因会随机失败，不过就算是加入重试还是会比nmake这种单进程快很多，同时不用大幅度修改Makefile模版。
2. 迷惑的参数设置导致配置平台极其复杂，并且对于未知参数***没有***警告，甚至直接加入cflags和lflags中。主机构建也需要像交叉构建一样传入平台当参数
不解释，用过的都懂。
OpenSSL说在Unix-ish系统上可以使用./config进行主机构建，不过。。。在macOS上用过的都知道这货不能用，而且这货是Shell脚本，仅限于Unix-ish系统，Windows还是没辙。
autoconf和CMake都有标准的方法配置各种编译器和工程构建行为。autoconf甚至支持./configure --help输出工程文件支持的行为，极大的方便了工程的使用者。而OpenSSL的构建系统。。。。。“你看，我这个构建系统支持这么多平台，太NB了”
3. autoconf和CMake都有很多主业是C语言的程序员在用，受众比Perl要广
相比之下主业是C语言的程序员会用Perl的就要少很多了。
最后说一下OpenSSL在这个贴子里的构建版本的使用情况：
现在还在构建的使用OpenSSL 1.1系列的现在只有Windows的Qt 5.12版本和安卓的所有版本了。
Windows下Qt 5.13以上的版本使用SChannel进行构建，摆脱了对OpenSSL的依赖。SChannel在较新的Windows下已经支持TLS 1.3了，等Windows 21H2发布之后可以看看MSVC版本的Qt 6使用TLS 1.3的表现。
macOS下Qt 5.6以上的版本使用SecureTransport进行构建，摆脱了对OpenSSL的依赖。不过这货被苹果弃用了。等TLS 1.3成为主流之后，还要换回OpenSSL。
WebAssembly下没有OpenSSL支持，QLibrary的锅。
安卓没办法，自从心脏出血之后Google就决定不在安卓里自带OpenSSL了，而是换用了谷歌自己从OpenSSL fork出来的BoringSSL，与OpenSSL源码和二进制都不兼容，Qt在安卓上只用OpenSSL，所以还是要自己构建。
以前的版本：
Qt 5.6/5.9的Windows和安卓版使用OpenSSL 1.0.2u，macOS版使用SecureTransport。
Qt 4.8的Windows和macOS版使用OpenSSL 1.0.2u。
OpenSSL 1.0.2系列构建系统不支持shadow build，源码不支持64位安卓，和1.1系列源码和二进制不兼容，已经被淘汰了。而且在Windows上构建使用的makefile都特立独行，像后妈一样。。。。