我是C ++库的作者,该库分布在多个Linux打包发行版中。 该库包括标题和来源; Linux软件包将其分发为标头+共享库(.so)。
我正在寻找能够让Linux软件包维护者的生活更轻松的指南。
我感兴趣的事情包括:
API兼容性(例如更改功能签名)。显然,维护次要版本之间的兼容性至关重要。主要版本更改怎么样?
二进制兼容性(例如,更改外部可见数据结构的大小)。在次要版本中兼容ABI有多重要?在主要版本中是否有任何问题?
构建版本控制建议。我目前正在使用CMake - 我应该设置的任何特定设置,以最大限度地提高程序包维护人员使用我的CMakeLists.txt的机会?
如果还有其他任何我想念的东西,我也很高兴听到它。
答案 0 :(得分:2)
让我来解决ABI问题。这在很大程度上取决于您是否会提供可在任何地方使用的预构建二进制文件,或者您是否依赖分销商为您构建它。
考虑Debian:一旦包在Debian中,构建主机就会在每个支持的平台上重新编译每个更新。 C ABI很少改变,但C ++ ABI需要特别注意(正如2005年给debian开发人员的消息中提到的那样:http://lwn.net/Articles/139810/)
我认为提供一个可以在任何地方使用的C ++包是不合理的。 ABI过于特定于网站:https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html
答案 1 :(得分:2)
作为一名Linux维护者,我可以说你的库的反向二进制(ABI)和源代码(API)兼容性对我们来说非常重要。
API更改可能会破坏依赖于您的库的分发中某些应用程序(或其他库)的重建。这可能会破坏分布的大规模重建。
ABI更改可能会破坏特定的二进制更新。我们需要验证更新库中的ABI更改,并在检测到某些危险更改时重建所有相关应用程序。在这种情况下,用户应该下载库的更新包以及所有相关应用程序。如果库是后向API且ABI稳定,那么我们只能更新库包。
如果您打破ABI,请更改您的图书馆的SONAME
(凹凸版本)。请不要在微/补丁版本中引入API / ABI更改。
我建议您使用abi-compliance-checker工具验证库是否具有API / ABI向后兼容性。请参阅Qt库工具的示例报告:http://abi-laboratory.pro/tracker/timeline/qt/
您需要使用-g -Og
个附加选项编译库的调试版本,并在abi-dumper工具的帮助下转储库的ABI。然后比较两个不同版本的ABI转储以生成ABI更改报告。