jbolt_platform_2-3 升级到pro

本文档详细介绍了如何从旧版JBolt系统平滑过渡到最新版本的步骤,包括代码迁移、业务数据导入等内容,适用于已经使用JBolt进行项目开发的技术团队。

jbolt_platform_2 id为自增
jbolt_platform_3 id为雪花
jbolt_pro为最新,也是未来持续更新版本

一 系统架设

1、下载最新pro版本源代码,按新系统架构完成。
2、把业务表所有id或者pid由int自增长改为bigint (3本来就是雪花不需要修改)重新将结构导入新系统
3、原系统jb_permission表内将自己添加的部分 导出导入新系统
4、运行一次model 和permission自动生成

二、源代码修改

1、将所有自己开发的js css java html全部移入新系统

2、在systemlog中自动ProjectSystemLogTargetType日志枚举信息,看作者wiki

3、所有日志修改,serivce均需要继承父类,实现

	@Override
	protected int systemLogTargetType() {
		return ProjectSystemLogTargetType.***.getValue();
	}

原来添加增删改记录日志地方,类型字段删除就行。

4、修改关键点


	dictionary get方法的使用参数加 true 
	msg -->JBoltMsg
	 DateUtil  -->  JBoltDateUtil
	JBoltUserKit.getUserIdAs() --> JBoltUserKit.getUserId()
	int userid  --> Long userid   所有id int定义全部改为Long
    Integer userId    Long userId  
 以下可直接替换
import cn.jbolt.base.JBoltBaseController;
import cn.jbolt.core.controller.base.JBoltBaseController;

import cn.jbolt.base.JBoltUserKit;
import cn.jbolt.core.kit.JBoltUserKit;

import cn.jbolt._admin.permission.CheckPermission;
import cn.jbolt.core.permission.CheckPermission;  

import cn.jbolt._admin.user.JBoltUserAuthKit;
import cn.jbolt.core.permission.JBoltUserAuthKit;

import cn.jbolt.common.config.Msg;
import cn.jbolt.core.base.JBoltMsg;

  DateUtil    JBoltDateUtil
import cn.jbolt.common.util.DateUtil;
import cn.jbolt.core.util.JBoltDateUtil;

import cn.jbolt.base.JBoltBaseService;
import cn.jbolt.core.service.base.JBoltBaseService;

import cn.jbolt._admin.permission.UnCheckIfSystemAdmin;
import cn.jbolt.core.permission.UnCheckIfSystemAdmin;

import cn.lxjy.map.util.CACHE;
import cn.jbolt.common.util.CACHE;


html部分

#(CACHE.me.getUserName
改为
#(JBoltUserCache.getUserName

#(CACHE.getDictionaryName
改为
#(JBoltDictionaryCache.getName

#if(hasPermission(cn.jbolt.base.JBoltUserKit::
改为
#if(hasPermission(cn.jbolt.core.kit.JBoltUserKit::

5、将原来业务数据重新逐表导入,数据不多可以考虑第一步就完成。

<think>好的,我现在需要帮助用户理解他们提供的CMake代码中基于不同平台定义宏和链接库的逻辑。用户之前的问题是关于如何根据CMAKE_PLATFORM的值来添加不同的定义和库文件,现在他们希望更深入地了解这段代码的意义。首先,我需要回顾用户提供的CMake代码片段。代码中使用了多个if-elseif条件判断,检查CMAKE_PLATFORM的值,并根据不同的平台添加不同的编译定义和库。例如,当CMAKE_PLATFORM是"linux-s32v-aarch64"时,添加-DBUILD_WITH_AIRUNNER;如果是"linux-xavier-aarch64",则添加-DBUILD_WITH_TENSORRT,并链接libtn_tensorrt_bridge.so。其他平台如TDA4系列和Ubuntu也有相应的处理。接下来,我需要考虑用户的需求。他们想理解这段代码的意义,也就是为什么需要根据不同的平台定义不同的宏和链接库。可能用户是刚开始接触CMake,或者对跨平台构建不太熟悉,需要解释这些条件判断的作用以及背后的原理。根据用户提供的引用,其中提到CMake用于管理项目结构,支持多级目录和库分割,以及find_package的使用。这些引用可以帮助我构建回答的结构,结合用户之前的提问历史,他们可能对如何在不同平台下配置构建选项感兴趣。我需要分步骤解释这段代码的逻辑。首先,CMAKE_PLATFORM变量的来源可能是什么?通常,CMake本身并没有内置的CMAKE_PLATFORM变量,可能是用户或项目自定义的变量,用来表示特定的目标平台。例如,不同的嵌入式系统如NVIDIA Xavier、TDA4等,可能有不同的架构和依赖库,因此需要条件编译。 接下来,每个条件分支的作用。例如,当平台是linux-xavier-aarch64时,添加TensorRT支持,并链接对应的库。这里需要解释为什么需要这样做,可能因为该平台支持TensorRT加速,而其他平台可能没有安装相关库或者需要使用其他加速框架。 然后,add_definitions的作用是添加预处理器宏,使得在代码中可以通过#ifdefBUILD_WITH_AIRUNNER等条件编译不同平台的代码。而list(APPEND BRIDGE_LIBS ...)则是将特定的库文件添加到链接器中,确保编译后的程序可以正确调用这些库的函数。用户可能还关心这些宏在代码中如何使用,例如在C++文件中根据定义的宏选择不同的实现。例如:#ifdef BUILD_WITH_TENSORRT#include<tensorrt_runtime.h>#endif此外,不同平台可能需要不同的依赖库路径或编译选项,这些都需要在CMake中配置,以确保跨平台兼容性。用户提供的引用中提到CMake的模块化和项目结构管理,所以可以结合这些点,说明条件编译如何帮助保持代码的模块化,每个平台特定的代码和依赖被隔离,便于维护。还需要注意,CMAKE_PLATFORM可能是通过工具链文件或外部脚本设置的,用于交叉编译场景。例如,在嵌入式开发中,不同的目标设备需要不同的工具链和库,CMake通过条件判断来适配这些差异。 最后,总结这段代码的意义,即实现跨平台构建的灵活配置,确保同一套代码可以在不同环境中正确编译和链接,利用各平台的特定功能和优化。 在解释过程中,需要确保专业术语准确,同时用易懂的语言让用户理解。可能还需要对比不同平台的处理方式,帮助用户看到差异和共同点。例如,为什么有的平台添加了库文件而有的只是定义宏,可能是因为某些库需要显式链接,而其他平台可能通过其他方式自动处理依赖。 另外,用户可能的问题会涉及如何检测平台、find_package的工作原理、CUDA的检测等,需要预先考虑到这些潜在的问题,并在回答中自然地引导用户思考,或者生成相关问题供他们进一步探索。</think>### 对CMake代码中平台相关逻辑的详细解释 #### 一、平台判断机制 这段CMake代码通过自定义变量`CMAKE_PLATFORM`的值判断当前编译目标平台,其核心逻辑可总结为: $$ \text{if}(P \in S) \rightarrow \text{添加对应平台特性} $$ 其中: - $P$表示`CMAKE_PLATFORM`变量值 - $S$表示平台标识符集合(如`linux-s32v-aarch64`等) #### 二、各平台分支的意义 1. **NXP S32V平台** (`linux-s32v-aarch64`) ```cmake add_definitions(-DBUILD_WITH_AIRUNNER) # 定义AIRunner框架的编译宏 ``` 该平台通常用于自动驾驶域控制器,`BUILD_WITH_AIRUNNER`宏可能在代码中启用NXP Vision SDK的特定优化[^1] 2. **NVIDIA Xavier平台** (`linux-xavier-aarch64`) ```cmake add_definitions(-DBUILD_WITH_TENSORRT) list(APPEND BRIDGE_LIBS libtn_tensorrt_bridge.so) # 链接TensorRT桥接库 ``` 这里通过`libtn_tensorrt_bridge.so`实现CUDA核心与TensorRT推理引擎的交互,典型应用于边缘AI推理场景[^2] 3. **TI TDA4平台系列** ```cmake # 注释掉的TensorRT支持表明该平台可能需要使用TI自有推理框架 ``` TDA4的C7x/C6x DSP架构通常需要调用TI的TIDL推理库,与TensorRT存在架构差异 4. **Ubuntu桌面平台** ```cmake add_definitions(-DBUILD_WITH_TENSORRT -DBUILD_WITH_PYTHON) ``` 同时启用TensorRT和Python绑定,支持开发阶段的混合编程需求[^3] #### 三、关键CMake命令解析 | 命令 | 作用 | 数学表达 | |-------------------------------|----------------------------------------------------------------------|-----------------------------------| | `add_definitions()` | 添加预处理器宏定义 | $D \leftarrow D \cup \{macro\}$ | | `list(APPEND)` | 动态扩展库文件列表 | $L \leftarrow L \cup \{lib\}$ | | `CMAKE_PLATFORM`比较 | 平台特征判断 | $P \in S_i \rightarrow A_i$ | #### 四、代码设计思想 1. **平台抽象层** 通过宏定义隔离硬件差异,例如: ```cpp #ifdef BUILD_WITH_TENSORRT void tensorrt_inference(...) { /* Xavier专用实现 */ } #else void generic_inference(...) { /* 通用实现 */ } #endif ``` 2. **依赖管理** `list(APPEND BRIDGE_LIBS ...)`实现库文件的动态装配,满足: $$ \exists lib \in BRIDGE\_LIBS \Rightarrow \text{链接阶段包含该库} $$ 3. **构建可配置性** 每个平台分支定义独立的特性集合,符合: $$ \forall p \in Platforms,\ \exists! Config(p) \subseteq Features $$ #### 五、典型应用场景 1. **交叉编译环境** 当使用`aarch64-linux-gnu`工具链时,通过`CMAKE_PLATFORM`指定目标设备类型 2. **异构计算支持** 不同加速芯片(GPU/VPU/DSP)需要绑定不同的计算库 3. **版本兼容处理** 例如TensorRT 8.x与7.x的API差异可通过平台宏隔离
评论 1
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值