Build overlay

[LorenzMeier]

@dagar @bkueng @mcharleb Some of our adopters have customisations that we are not interested in (e.g. weird airframe configs) or they can't share (custom applications specific to their product).

I want to enable them to use upstream PX4 without rebasing stuff on top or generally having a tainted source tree. I'm trying to work out an overlay scheme that makes it easier to stay up-to-date with current PX4 and contribute back.

The overlay should also enable them to keep their code in a separate directory, which makes them more comfortable working with upstream.

• Overlay
  • Firmware
    • custom ROMFS
    • custom cmake config
    • custom apps
    • custom board configs

This doesn't seem like a new problem. Is there a build system or at least design pattern we can reuse?

[dagar]

I'll do some research, but nothing immediately comes to mind for a canned solution to use or replicate. Really all we need is a handful of general build system and organization changes that make it seamless for these things to exist out of tree as first class citizens.

We should list the most common specific use cases and go through solving each.

• custom ROMFS
  • mixer
  • airframe configuration
  • rcS hacks <- disappointingly common. PX4 init is becoming a confusing mess (not even considering non-nuttx platforms). Can we make it more modular (init levels?) with the ability to extend at the appropriate points. Pushing as much configuration into params handled by the module itself tends to help.
  • pwm configuration is way more complicated than it needs to be
• custom cmake config
  • grouping sets of modules to enable/disable with configuration flags? There's got to be a beter way than this https://github.com/PX4/Firmware/blob/master/cmake/configs/nuttx_px4fmu-v3_default.cmake#L9
  • we could explore scanning and including all modules recursively with some simple optional metadata. Auto exclude if a module is only for a particular platform, etc.
• custom apps
  • we already have external modules, although it's not intuitive. There's a lot of PX4 cmake that's little more than a thin cmake wrapper and feels like NIH syndrome. It gives people the impression the build is way more complicated than it actually is.
• custom board configs
  • much better than it used to be, but maybe each board can be completely contained to a single directory
  • per board init files for starting sensors, default parameters, etc
  • board naming is unnecessarily verbose. platform_config_label. It already knows the platform from the toolchain (defined in each cmake config). Almost all are _default.

Another little idea that might help is to make it as easy as possible to sub out entire modules. For example many want to customize the attitude/rate controller in some way. If it was trivial and obvious the preferred solution could be to duplicate the entire module and then customize rather than hack in place.

[dagar]

Tagging @davids5 to discuss nuttx options.

[mcharleb]

This brings me back to using a manifest file and repo to specify the collection of git repos used for a particular build target. I find that git submodules just isn't flexible enough to handle builds with optional modules. The manifest is much more succinct about what is or isn't in a particular build and will drive better modularity.

[dagar]

Another related idea would be to make it easier for a non developer to customize the release file *.px4) with a custom airframe, mixer, params without needing to embed the configuration in the firmware and rebuild everything.

[ksschwabe]

Quote by @dagar in PR #9097:

I'd strongly recommend adding something basic to the CI system that tests the various EXTERNAL module pieces. Otherwise it's very easy to unintentionally break.

[dagar]

@ksschwabe if you could put together a simple repository that's representative of the different build overlay mechanisms (EXTERNAL modules and messages), I'll add it to the CI system quickly. In SITL we could have a trivial test that checks for the message and module.

[ksschwabe]

@dagar: Sorry I haven't quite managed to get to this yet - hopefully I can put this together by the end of the week. What exactly do I need to do here? Just set up a very simple "external repo" with a few modules and externally defined uORB messages?

Would I need to add anything to it for the CI, or will you handle that once I have set up the repo?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

Closing as stale.