【发布时间】:2020-08-28 08:36:55
【问题描述】:
我已开始在 Xilinx 的 Vitis IDE 下开发软件,但我发现了有关源代码版本控制的问题(以 Mercurial 为例)。 Vitis IDE 中的源代码可以分为两部分:
- 应用程序代码,完全由软件开发人员控制
- 所谓的平台代码(外围设备、bsp 和 os 的驱动程序),它是基于自动生成的 通过 tcl 脚本在特殊的硬件相关 xsa 文件上。
基于此,我决定对以下文件进行版本控制:
- 应用程序源文件(.c、.h)
- xsa 文件
- tcl 脚本
所以我创建了一个名为 RESOURCES 的存储库,其结构如下:
- hw_config - 包含 xsa 文件
- 脚本 - 包含 tcl 脚本
- src - 包含应用程序的源文件
基于 RESOURCES 存储库的内容,tcl 脚本在 WORKSPACE 目录中创建 Xilinx Vitis 工作区,结构如下:
- 应用程序代码(使用 RESOURCES 中的 src 副本)
- 平台代码
这种方法有一个严重的缺点,即应用程序源代码的更改是在 WORKSPACE 中完成的,但只有 RESOURCES 处于版本控制之下。因此,有必要将更改从 WORKSPACE 复制到 RESOURCES 以便能够提交它们。我认为这很不舒服并且容易出错。所以我一直在想一些更好的解决方案。我有一个想法准备一些脚本来监控工作空间中的变化,如果发现任何变化,它将启动将工作空间的内容复制到资源中。你认为这是一个好方法吗?提前感谢您的任何建议。
【问题讨论】:
-
您能否更清楚地描述一下您的目录的树结构?
-
通常将您正在更改的区域(术语中的WORKSPACE)置于版本控制之下。反之则容易出错且很奇怪。
-
@Donal Fellows 我同意你的看法。我这样做的原因是工作空间是通过tcl脚本根据xsa文件和源文件自动生成的。
-
您能否显示任何严重退化项目(应用程序代码中的一个|两个文件,平台代码中的一个驱动程序|os)的完整树(带有文件)?我只是不明白,为什么您必须将构建工件复制回源代码
标签: version-control mercurial tcl xilinx