My apologies if this chosen discourse category is not the best for this question…
The primary topic of this post is on Ardupilot’s GitHub branching and build strategy. I had previously been questioning this topic in my mind, and my recent experience with implementation of the Lua require has now prompted this post.
Before getting to the primary topic, I’d like to share my recent experience with the Lua require that prompted me to create this post.
I had been trying to get Lua require working across all three of the following implementations:
- Lua copied to scripts folder for Simulation Copter, e.g., C:\Users\…\Documents\Mission Planner\sitl+\scripts
- Lua uploaded to scripts folder on SD card of Cube Orange+
- Lua embedded in ROMFS_custom/scripts folder of our own OEM build of Ardupilot firmware for Cube Orange+
To get it working across all three implementations I added multiple paths to the package.path variable as shown in the scripting example that follows. The comments in the scripting example provide a good summary.
-- The package.path specifies the search path for Lua files. The package.path
-- must be appended as follows to support the Lua **require** statement:
--
-- /scripts/?.lua - Path needed to locate required scripts on the Simulation
-- Copter.
-- /APM/scripts/?.lua - Path needed to locate required scripts on the SD Card
-- of Cube Orange.
-- @ROMFS/scripts/?.lua - Path needed to locate required scripts embedded within
-- our custom build of the Ardupilot firmware for Cube Orange.
package.path = package.path .. ";/scripts/?.lua;/APM/scripts/?.lua;@ROMFS/scripts/?.lua")
gcs:send_text(6, string.format("package.path=%s", package.path))
require("MyRequiredLuaScript")
Main script...
Resulting package.path:
package.path=/APM/scripts/modules/?.lua;/APM/scripts/modules/?/init.lua;./?.lua;./?/init.lua;/scripts/?.lua;/APM/scripts/?.lua;@ROMFS/scripts/?.lua
Getting into the primary topic…
As of this writing, the Copter 4.5 branch is 3000+ commits behind the master branch and 400+ commits ahead of the master branch.
We are building our OEM firmware off of Copter 4.5.4 (GitHub commit hash: 3f5289f4f6068fdce9c2ddbc539405431471ecec). I do realize 4.5.4 is not the latest stable release, but that is beside the point here.
While troubleshooting the Lua require issues in my journey to a working solution, I reviewed multiple discourse discussions and GitHub merge requests related to the topic of the Lua require. In that review I found the following changes under commit c7d543f9af1dcb9bbcc66e1ecd6a8aa8ce8d8c42.
Would including the above commit in my OEM build, perhaps with other related changes, have allowed me to omit including the @ROMFS/scripts path in the package.path update in my scripting??? I don’t know, but I suspect it might.
Commit c7d543f9af1dcb9bbcc66e1ecd6a8aa8ce8d8c42, containing the ROMFS changes, is on the master branch as of Feb, 26, 2024.
Commit c7d543f9af1dcb9bbcc66e1ecd6a8aa8ce8d8c42 is not on the Copter 4.5 branch.
Given all that I understand here with the Ardupilot branches, it seems that if I want to build my OEM version off of one of the Copter 4.5 versions, then I need to do so off of the Copter 4.5 branch. Yet, the Copter 4.5 branch does not contain other changes (Lua require changes as an example) that are present on the master branch. Hence all this leads me to trying to understand Ardupilot’s branching and build strategy.
I realize I could cherry pick commits from master to merge into my own Copter 4.5 branch, but that approach seems like a large potential to introduce errors.
Assuming all the above makes sense, what am I missing here in my approach towards generating my own OEM builds off of Copter 4.5, while wishing to take advantage of other enhancements that only reside on the master branch?
Are the changes on the master branch reserved for future 4.6 or future 5.x?