git - 如何在源代码控制下获取 buildroot 项目

Question

我工作的公司开发了一种需要嵌入式 Linux 的产品，我们使用Buildroot和其他许多产品。

无论如何，我希望使用 Git 对项目进行源代码控制，因为它是我们对公司所有其他项目进行源代码控制的工具。问题是我不知道应该将哪些文件保留在源代码管理中（因为保留整个buildroot目录似乎有点过分了）。

Answer 1

我通过使用git submodules和buildroot br-external功能解决了同样的问题。

从这个意义上说，您只需要启动一个空存储库并导入一个 buildroot 版本作为它的子模块。

mkdir myrepo; cd myrepo
git init
touch README; git add README; git commit -m "Initial commit"
git submodule add -b <preferred release/tag/branch> git://git.buildroot.net/buildroot
git submodule update --init

然后，您可以创建一个br-external目录并将其填充为类似于 buildroot 自己的 package/configs/board 目录，如BR2_EXTERNAL文档1中所述。

mkdir br-external
# below command assumes you have all structures ready somewhere else
cp -fva .../configs .../package .../board br-external
touch br-external/{Config.in,external.mk}
(edit Config.in and external.mk)
git add br-external

这样做之后，您只需要运行 buildroot defconfig 步骤，将绝对路径传递到您的 br-external 目录，如下所示。

make BR2_EXTERNAL=$PWD/br-external -C buildroot <boardname>_defconfig

您的 BR2_EXTERNAL 位置被缓存以供进一步调用。

最好的部分是您只需要对 br-external 内部的内容进行版本控制，buildroot 会以一种所有自定义内容都被正确分离的方式构建配置菜单（“用户提供的选项”菜单条目）。

此外，如果您决定将 buildroot 版本升级到较新的版本，唯一的麻烦就是升级子模块并提交它。非常适合配置管理。

cd buildroot
git pull origin latest-release
cd ..
git add buildroot
git commit -m 'buildroot latest-release upgrade'

Answer 2

我最近在我们的组织中解决了同样的问题，我发现这是一个有趣的话题。我将在这里描述我们的部分解决方案：

管理您使用的 buildroot 版本

编辑：最近的经验对我来说强调了这一点。

Buildroot 为每个 Buildroot 版本编写不同的配置文件。为了能够共享这些，您需要向所有相关人员指定您的存储库使用的 Buildroot 版本。

1. 您可以将 Buildroot 作为 git 子模块包含在您的存储库中。好的，如果您的公司只有一个 Buildroot 项目。
2. 在 README 文件中指定要使用的版本，或为其编写自定义检查。

建立树外

我强烈建议从树中构建：http: //buildroot.org/downloads/manual/manual.html#_building_out_of_tree

$ cd ~/platform/proj-arm; make O=$PWD -C path/to/buildroot

将配置文件和目标覆盖添加到 git

将 .config 文件和子配置文件添加到 git 存储库。我的回购包含以下内容：

.config
README.md
linux.config
build/busybox-1.22.1/.config
libdc1394.patch
opencv_2.3.1a.patch
target-overlay/README~
target-overlay/etc/dropbear/dropbear_ecdsa_host_key
target-overlay/etc/dropbear/dropbear_rsa_host_key
target-overlay/etc/fstab
target-overlay/etc/httpd.conf
target-overlay/etc/init.d/S51mount_html
target-overlay/etc/init.d/S52new_ip_address
target-overlay/etc/init.d/S53httpd
target-overlay/etc/network/interfaces
target-overlay/etc/shadow
target-overlay/etc/sshd_config
target-overlay/lib/firmware/rtl_nic/rtl8168g-2.fw
target-overlay/root/.ssh/authorized_keys

将您对 buildroot 的更改保存为补丁

每当您更改 buildroot 存储库中的内容时，就针对该功能进行分支，并为其创建补丁。将补丁保存在您的存储库中，并使用 README.md 文件向其他人解释如何将其应用于 buildroot 树。

Answer 3

你有两个基本的选择。

1. 最简单的方法是克隆 buildroot 存储库（它不是很大）并根据发布标签创建自己的分支。这使您可以轻松地对 buildroot 进行修改，但很难制作全局标签和分支（即为 buildroot 和您自己的代码提供相同的标签）。但是，如果你想将它与你自己代码的存储库结合起来（这样所有东西都可以标记在一起），你必须使用 git submodules 或 subtree merging（这两种方法都不是很方便），或者你必须将其保留为单独的存储库并使用第二种解决方案进行集成。
2. 您可以将您的产品基于 buildroot tarball 并编写一个构建脚本来下载 tarball、提取它、配置它（通过调用 *make xxx_defconfig*）并构建它。最近添加的 BR2_EXTERNAL 机制（将在 2014.02 中发布）使您可以轻松地将自己的添加保留在 buildroot 树之外。但是，如果您需要更改核心基础架构中的任何内容，则必须在下载的 tarball 上应用补丁，这很不方便。

在您的存储库中提取 buildroot tarball 并像这样导入它当然不是一个好主意，因为这使得更新您的 buildroot 树甚至应用上游补丁变得困难。如果您确实希望在自己的存储库中使用它，请使用 git subtree merge 以便至少保留上游历史记录。

第三种选择是使用 Android 的repo工具来组合 buildroot、linux、您自己的代码和您修改的其他包的 git 存储库。这结合了我给出的两个选项中最好的一个（易于修改并支持全局标签/分支）。但我自己从未尝试过，所以我不能保证它会很好用。