管理C++的第三⽅库以及编译
第三⽅库这个说法，不知道出⾃哪⾥，但⼀般是指开发者，系统/平台提供商之外的第三个参与者提供的程序库。⼤多数开源软件库在软件系统中都是第三⽅库。
源代码下载开源社区完全不使⽤库的开发，在90年代就已经被放弃了，特别MFC/OWL/QT这些先⾏者。开源运动的兴起使得第三⽅库成为主⼒使⽤库。
C++领域有⼀些⾮常特殊的库，⽐如早期的STLport和当前的Boost，它们就像是语⾔的事实标准，基本在每个程序中都可以见到他们的⾝影。
但第三⽅库也会导致相当多的问题，主要总是包括：
1. 版本不⼀致。同⼀个软件系统中，如果引⽤了同⼀个第三⽅库的两个不同版本，那⼀定会暗⽣问题。
2. 编译选项不⼀致。⼀般为了减少编译时间，第三⽅库都会以编译后的.a/.lib形式参与软件编译，第三⽅库的编译选项与软件系统的编译选项不
同，也是会有⼀些潜在的问题。特别是x86/x64，ansi/utf-8这些选项不同，根本就不能⽤。
3. 版本管理库变⼤。在⼀些⼤项⽬中常常会有⼏个G的版本库，每次clone代价很⼤。其实很多都是第三⽅库，不同版本，不同编译选项⽣成的库
引⼊。
除了把编译的库引⼊项⽬，也有⼈以源代码的形式引⼊开源软件，⽐如GCC、SDL、WxWights、QT。如果第三⽅库本⾝编译不复杂，原代码也很简单，这么做⽐较好。
但是像Boost.Thread这样的库，就不⾏了。它需要编译成动态库，静态引⽤会有问题。
另⼀⽅⾯，如果第三⽅库升级，就是⼀个⽐较复杂的⼯程，如果不升级，⼜只能看着第三⽅库的问题得不到解决。
在Linux上这个问题并不严重，系统级的软件管理⼯具可以代管⼤多数的第三⽅。⽐如debian系的，可以使⽤apt得到⼤多数的开源库，同时如果需要最新版本，也可以通过第三⽅源来取得。
在交叉编译和window平台上这个问题就⾮常头痛了。我们需要从⼏个层次来解决这个问题。
1. 需要有中⼼化的第三⽅源代码获取平台，这个平台需要⽀持按⽤户/组织+第三⽅库+版本的形式取得源代码，同时还需要保证及时跟踪来源。
这个类似于bintray/github都可以。公司内部可以使⽤gitlab来搭建。
2. 需要有⼀个构建脚本平台，存放在不同⼯具链和平台的情况下，这个脚本可以从源代码中⼼的源代码，把源代码编译成库。同样可以⽤github
这类⼯具搭建和管理。
3. 在项⽬中提供⼀个配置⽂件，需要的开源库（只需指定编译脚本，脚本是针对开源库）。这个只需要⼀个⽂本⽂件即可。
4. 在开发者的机器和编译服务器上，下载编译脚本，⽣成库。源代码、最终结果可以缓存在本机上。可以使⽤项⽬原本的构建⼯具。
如果只考虑windows+vc这个⼯具链，最简单的⼯具是使⽤msbuild，即为第三⽅库构建⼯程，编译结果⽣成成为vcprops⽂件，由项⽬引⽤。在项⽬⼯程中，可以通过prebuild过程加上下载、编译、安装第三⽅库的过程，因为有缓存，每台机器上应该只需要做⼀次。
考虑Boost这个最常⽤的库，并没有⼀个msbuild可以调⽤⼯程，这个⽅案通⽤性很差。但对于只使⽤vc的公司还是⾮常实⽤。因为只需要⼀个内源的源代码管理⼯具就可以了，没有git甚⾄可以⽤svn。
如果有多平台交叉编译，要考虑先统⼀项⽬⾃⼰的编译⼯具，使⽤CMake/Scons/Gyp这些跨平台编译⼯具，否则需要在不同的编译⼯具下都做⼀套。
以CMake为例，最接近这个系统的是CPM这个⼯具，它⽤github做前两个服务器，CMake的脚本来完成下载，编译。但受CMake脚本的能⼒限制，它⽆法完成更复杂的版本管理⼯作，只能做为⼀个试验原型。
使⽤CPM，可以先把⾃⼰的项⽬改成使⽤CMake编译，在中引⼊CPM语句，再引⼊需要的第三⽅库。如果第三⽅库已经在有⼀个CPM脚本⼯程，就很简单直接引⽤即可。但如果没有，就需要⾃⼰先建⽴CPM脚本⼯程。即⼀个，可以下载编译第三⽅库，再提供CPM⼀些专⽤宏，以便后续项⽬能到这个第三⽅库。
⼀个内源第三⽅库（指公司内共享库）需要两个git⼯程（或svn⽬录），⼀个提供原始代码和维护⼯作，另⼀个提供构建脚本，这个脚本甚⾄可

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。