linphone-sdk-android版本号生成解析
前言
好久没写 linphone-sdk-android
相关的文章了,本文记录下笔者分析 linphone-sdk
版本号生成的过程。
分析
注:以下源码基于 linphone-sdk-android 4.5.26。
修改完 linphone-sdk
的源码后总是要编译的,编译完成后我们就可以得到一个带有版本号的 aar
包,那么这个版本号是从哪里来的呢?
编译产物
首先看下编译完成后 build
目录下的产物,会发现有两个 gradle
脚本文件:build.gradle
和 upload.gradle
,打开 upload.gradle
脚本文件,在里面发现如下代码:println("AAR artefact group is: " + artefactGroupId + ", SDK version 4.5.27")
,其中 4.5.27
就是 linphone-sdk
的版本号。
根据前面文章的分析,编译产物一般是自动生成的,所以笔者在 linphone-sdk
目录下搜索 upload.gradle
:find . -name '*upload.gradle*'
:
./cmake/Android/gradle/upload.gradle.cmake
./build/upload.gradle
果然找到了,其中第2行是笔者刚才打开的文件,找到并打开第1行的文件 upload.gradle.cmake
,与第2行的文件对比,发现前者就是后者的模板文件,在 upload.gradle.cmake
文件中发现:println("AAR artefact group is: " + artefactGroupId + ", SDK version @LINPHONESDK_VERSION@")
,其中 @LINPHONESDK_VERSION@
就是 linphone-sdk
的版本号了。因为此文件后缀是 .cmake
,那么联想 @LINPHONESDK_VERSION@
应该是个 cmake 参数。
接下来在 linphone-sdk
目录下搜索包含 LINPHONESDK_VERSION
字样的文件:find . -type f | xargs grep 'LINPHONESDK_VERSION'
,本次查找结果较多,就不贴出来了,经过笔者的对比分析,锁定了最后一行结果:./CMakeLists.txt:bc_compute_full_version(LINPHONESDK_VERSION)
。
CMake
打开 ./CMakeLists.txt
,在前几行就可以找到如下代码:
include(bctoolbox/cmake/BcToolboxCMakeUtils.cmake)
bc_compute_full_version(LINPHONESDK_VERSION)
其中第2行代码 bc_compute_full_version
就是计算 linphone-sdk
版本号的函数,其定义在第1行代码中的 BcToolboxCMakeUtils.cmake
中,打开 BcToolboxCMakeUtils.cmake
文件并找到 bc_compute_full_version
函数:
function(bc_compute_full_version OUTPUT_VERSION)
# 查找 Git 程序
find_program(GIT_EXECUTABLE git NAMES Git CMAKE_FIND_ROOT_PATH_BOTH)
# 如果找到 Git 程序
if(GIT_EXECUTABLE)
# 执行 git describe 命令
execute_process(
COMMAND "${GIT_EXECUTABLE}" "describe"
OUTPUT_VARIABLE GIT_DESCRIBE_VERSION
OUTPUT_STRIP_TRAILING_WHITESPACE
ERROR_QUIET
WORKING_DIRECTORY "${CMAKE_CURRENT_SOURCE_DIR}"
)
# parse git describe version
# 解析 git describe 的返回值作为版本号, 通过正则表达式的分组匹配进行解析:4.5.26-alpha-9-gb342a93
# 如果没有解析到, 输出错误信息
if (NOT (GIT_DESCRIBE_VERSION MATCHES "^([0-9]+)[.]([0-9]+)[.]([0-9]+)(-alpha|-beta)?(-[0-9]+)?(-g[0-9a-f]+)?$"))
message(FATAL_ERROR "invalid git describe version: '${GIT_DESCRIBE_VERSION}'")
endif()
# 设置分组1为主要版本: ([0-9]+) -> 4
set(version_major ${CMAKE_MATCH_1})
# 设置分组2为次要版本: ([0-9]+) -> 5
set(version_minor ${CMAKE_MATCH_2})
# 设置分组3为补丁版本: ([0-9]+) -> 26
set(version_patch ${CMAKE_MATCH_3})
# 如果解析到分组4: (-alpha|-beta)? -> -alpha, 则去掉前面的‘-', 得到后面的‘alpha|beta', 赋值给 version_prerelease
if (CMAKE_MATCH_4)
string(SUBSTRING "${CMAKE_MATCH_4}" 1 -1 version_prerelease)
endif()
# 如果解析到分组5:(-[0-9]+)? -> -9, 则去掉前面的‘-', 得到后面的‘9', 赋值给 version_commit
if (CMAKE_MATCH_5)
string(SUBSTRING "${CMAKE_MATCH_5}" 1 -1 version_commit)
endif()
# 如果解析到分组6: (-g[0-9a-f]+)? -> -gb342a93, 则去掉前面的‘-g', 得到后面的‘b342a93', 赋值给 version_hash
if (CMAKE_MATCH_6)
string(SUBSTRING "${CMAKE_MATCH_6}" 2 -1 version_hash)
endif()
# interpret untagged hotfixes as pre-releases of the next "patch" release
# 如果没有 version_prerelease, 但是有 version_commit, 认为是此补丁程序是下一个补丁版本的预发版本, 即将补丁版本号+1
# 并设置 version_prerelease 为 "pre"
if (NOT version_prerelease AND version_commit)
math(EXPR version_patch "${version_patch} + 1")
set(version_prerelease "pre")
endif()
# format full version
# 拼接主、次、补丁版本号
set(full_version "${version_major}.${version_minor}.${version_patch}")
# 如果有 version_prerelease
if (version_prerelease)
# 版本号追加 "-pre"
string(APPEND full_version "-${version_prerelease}")
# 如果有 version_commit
if (version_commit)
# 版本号追加 ".9+b342a93"
string(APPEND full_version ".${version_commit}+${version_hash}")
endif()
endif()
# 省略其他检查逻辑
# 设置版本号为CMake缓存参数, 完整版本号: 4.5.27-pre.9+b342a93
set(${OUTPUT_VERSION} "${full_version}" CACHE STRING "" FORCE)
endif()
endfunction()
下面就是分析 bc_compute_full_version
函数了。
首先查找 Git
程序,如果找到 Git
程序,函数才会继续,否则无法计算版本号。
找到 Git
程序后会执行 git describe
命令,此命令会基于当前可用的 ref 给一个人类可读的名称。
- 如果当前最新的 commit 上有 TAG,且 TAG 必须有描述信息或者带有
-- tags
参数,此命令则返回此 TAG 名称:4.5.26, - 否则返回离当前最近的 TAG 名称 + 此 TAG 之后的提交次数 + 当前的 commit hash 值前 7 位:4.5.26-9-gb342a93,其中 'g' 表示是
Git
,
具体可查看 git-describe。
假设 git describe
命令返回的是:4.5.26-alpha-9-gb342a93
,接下来通过正则表达式的分组匹配解析返回的结果。
正则表达式:
^([0-9]+)[.]([0-9]+)[.]([0-9]+)(-alpha|-beta)?(-[0-9]+)?(-g[0-9a-f]+)?$,
其分为以下 6 组:
([0-9]+)
为第一组CMAKE_MATCH_1
,对应 4,([0-9]+)
为第二组CMAKE_MATCH_2
,对应 5,([0-9]+)
为第三组CMAKE_MATCH_3
,对应 26,(-alpha|-beta)?
为第四组CMAKE_MATCH_4
,可为空,对应 -alpha,(-[0-9]+)?
为第五组CMAKE_MATCH_5
,可为空,对应 -9,(-g[0-9a-f]+)?
为第六组CMAKE_MATCH_6
,可为空,对应 gb342a93,
分组一、分组二和分组三分别作为主要版本、次要版本和补丁版本:4.5.26。
如果解析到分组四: -alpha
,则去掉前面的 -
,得到后面的 alpha
,并赋值给 version_prerelease
变量;如果解析到分组五: -9
,则去掉前面的 -
,得到后面的 9
,并赋值给 version_commit
变量;如果解析到分组六: -gb342a93
,则去掉前面的 -g
,得到后面的 b342a93
,并赋值给 version_hash
变量。
如果没有 version_prerelease
变量,但是有 version_commit
变量,则认为此补丁程序是下一个补丁版本的预发布版本,即将补丁版本号增加一个版本并赋值version_prerelease
变量为 pre
。
拼接主要版本、次要版本和补丁版本为:4.5.27
,并赋值给 full_version
变量。
如果有 version_prerelease
变量,则 full_version
变量追加 -pre
,此时版本号为:4.5.27-pre
;如果有 version_commit
变量,则版本号再追加 version_commit
和 version_hash
变量的值 .9+b342a93
,得到版本号:4.5.27-pre.9+b342a93
。
最终得到 linphone-sdk
的版本号:4.5.27-pre.9+b342a93
。
总结
本文记录了笔者查找 linphone-sdk
生成版本号的过程,同时分析了版本号的生成逻辑,linphone-sdk
通过获取 Git
提交记录和 TAG 来生成版本号:
- 执行
git describe
命令获取可读Git
提交信息, - 通过正则表达式的分组配置模式解析得到的
Git
提交信息, - 最后根据分组信息修正并拼接得到完整的版本号。
利用 Git
提交信息来生成版本号这种方式,我们在写 SDK 时或许可以借鉴下。
以上就是linphone-sdk-android版本号生成解析的详细内容,更多关于linphone sdk android 版本号的资料请关注编程网其它相关文章!
免责声明:
① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的,并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据,供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。
② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341