Improvement suggestion - compile inside the flasher
timemaster5 opened this issue · 9 comments
I don't know whether this is a viable idea, and I am afraid it is not because of QT dependency, for example. But I have seen recently a nice ExpressLRS Configurator, they have basically offloaded their building process to their clients by integrating the ELRS Configurator written in Electron with Platform.io. This way, they build FW files on client machines on-demand without the need for their own build system. So I thought, we already have a nice minimalistic flasher, which could maybe do this in future and this way, resolve a discussion about what options to include or not and leave it on users, maybe in a better and more granular way then supported by original OpenTX Companion.
Ok so I think i understand, you basically are looking for basic model editing/companion functionality in the flasher? So the project is eventually going to use YAML for configuration on the radio, and I have already started working on a configuration screen for editing radio settings and models using YAML. Let me know if there is anything i missed
I am sorry, it was a terrible explanation of mine. I will change the title slightly.
What I meant was to compile on a client machine. I am attaching a screenshot of the ExpressLRS configurator.
I don't know much about your resources. I assumed that it might be easier to utilise users machines instead of compiling hundreds of images somewhere else and uploading them. It would allow more flexibility for the end-users as they could select what features they want to build, potentially reduce some workload and the need for resources on your side. It could also speed up a development process by giving users an easy way to build a nightly image or so.
From what I know, ExpressLRS uses Platform.io to gather all dependencies on the client machine and run a compile process.
BTW: model editing with YAML backed data is great too, looking forward to this feature!
If it were feasible, it would be great, but due to the complexities of the build process, it probably won't be. The nearest best option would be to use docker to be able to provide the required build environment, and then have some way of automating that... but even that is a pretty ugly process. ELRS is fortunate in the fact that the hardware they need to support is basically "just there" in PlatformIO, meaning the PlatformIO build system can be used - but this is also not an accident, as they basically started with readily supported microcontrollers.
I think Platform.io is not mandatory. Docker could be a good alternative. I've seen the repo. Maybe the question is whether to invest time. Does this feature sound like it would help the community? End-users or developers/maintainers?
From my perspective, it would allow me to get a customised image. Such images are not being published at a time together with the official stable release. And it would move us closer to the original OpenTX companion, where the user can select features he wants/needs.
Maybe there is some other plan on how to deal with different feature sets for different radios. Or is just better to compile all permutations and upload them together with the stable release. Which doesn't sound right to me, but understand why it was a better choice for OpentTX back then.
When we have a funding/accountancy model in place, we'll then be able to organize hosting and servers for customisable builds just like is done with Companion - where it checks to see if those build options have been used already and there's already a firmware file cached, or builds it on demand and caches it for later.
At present, the path of least resistance to compile yourself is to either use VSCode and the devcontainer support present there - which will get an end user setup with docker pretty much automatically. Alternately, a free gitpod account and using the link at the top of the edgetx repo readme gets you a docker setup on gitpods servers, and it's just a matter of building the firmware and downloading the file.
I'm not saying that this wouldn't be a good feature. Just from my perspective, we've already made this as simple as it can be for now given time, skill and resource constarints. i.e. being able to use the VSCode devcontainer support "magic" and use docker, or set up docker yourself, rather than a complex native build environment. For those who want native build environments , Risto has done excellent build guides for Windows and Linux as well, and there are also notes now how to get started with WSL2/docker as well.
Thank you for sharing these plans. I didn't know about it. I think we can close this one because my suggestion was to bypass a need for a custom build system. But if it is a plan and not a problem for you, it is not important to compile inside the companion app. I only had a feeling that this might be a way for people to hop on faster, and for me personally, it was a reason to try ELRS.
I can't agree more... what the ELRS guys have managed to do with offloading the compile work on to the end-users systems is nothing short of miraculous! It's just not something we could do with the build requirements being what they currently are. It may just be a matter of someone coming up with a viable alternative - just have to see what happens. I would certainly love the same to be able to happen for EdgeTX.
If I could move this forward, even as a proof of concept, I will let you know. By then, fair enough, and thank you for all your thoughts :)