Create an official docker container for OpenSource-EBike development

[geeksville]

I think we should use dockercontainers for 'official' release builds. Devs could still develop without using docker if they want, but docker costs very little CPU from the dev and it solves all problems of macos vs windows vs linux building (because to the build it always seems like linux). And it also allows us to make standard compiler selection choices.

If a dev wants to change the official compiler version etc... they would just edit the docker config file and send in a pull request.

What do ya'll think?

If people are okay with the idea I'll make a container which can be used to build: SW102 (nordic tools etc) 850C (stm32 tools etc) LCD3 (stm8 tools etc) Motor controller (stm8 tools etc) Openocd (for debugging the targets above)

copypasta from dev chat:

also anyone opposed to me adding something like https://circleci.com/open-source/ to our builds? (so that on each github PR it automatically will do test builds for both the 850C and SW102 to make sure that everything builds clean and without warnings)

oooh- circleci is docker based! So it seems the first step before using circleci is to make a dockercontainer which devs could (optionally - but I'll switch to using it) use for our build. The great thing about docker is that it removes all the 'windows vs macos vs linux build problems + tool version problems'). (For some slight runtime cost when running on the non native build platform - i.e. if I make a similar docker container based on linux the cost is only a couple of percent of CPU if running that container on linux, and only few percent more if instead you are developing on windows/os-x)

Good tutorial here: https://dev.to/dalimay28/using-docker-for-embedded-systems-development-b16

[geeksville]

Another nice aspect of this is: If some new dev is ever having a problem when they are not using docker (which should always be allowed btw), we can point them at the Dockerfile and they can see the exact commands for installing our build tools.

[casainho]

I like the idea although I ignore all this, but I am very happy to have the opportunity to learn!!

1. What are the costs?

KT-LCD3 development is stopped. We need to forget about it. What I think we need to have:

• SW102
• 850C
• TSDZ2

The TSDZ2 repo contains also the sources for KT-LCD3, which I think is not a good idea and need to be achieved.

Is that a good idea to keep both displays on the same repo? At least I understand that every time I need to write an issue, I need to make a label like "850C: issue"...

[geeksville]

@casainho

re: lcd3 I agree, I was more thinking of TSDZ2 but since the tools are the same I through it in there.

re: costs The cost when building on a linux host is only a couple of % of CPU. Cost when building on windows or OS-X the cost is about 6% of CPU (the last time I checked - which was a few years ago)

re: Is that a good idea to keep both displays on the same repo? At least I understand that every time I need to write an issue, I need to make a label like "850C: issue"... IMO OMG yes ;-) Because they share so much code - fixing the same bug twice sucks (and even more so when we add support for a third display type someday). Implementing v20 comms twice would suck. Most issues should be common anyways. Forking code is almost always the wrong choice (really bad software engineering practice)

In fact, even in a single repo it is usually a bad thing to copy paste a large section of code. Because someday you'll have a bug in that code and you don't want to have to fix the bug in 20 now slightly mutated copies of some original five-10 line snippet. Much better to decompose into a reusable function shared by both usages.

[geeksville]

For instance, the only opened issue with 850C tag: https://github.com/OpenSource-EBike-firmware/Color_LCD/issues/29 is not 850c specific. This enhancement request would also apply to sw102

[casainho]

1. Costs: I would like to know if there are money costs associated at something like an online service to use/run Docker.

For the processing changes to my setup, I am a bit worried because:

• I am using an Intel I3 on a 8.9 inches portable computer GPD P2 Max, and the current build process is not that fast already. But it has 16 GB of RAM, so should be ok for some extra virtual machine or something.
• I use every time the GITG and MELD visual software to look at the source and changes, I really need to keep using them

Ok for common repo, and I totally agree now that I have more experience, like I just implemented #29 today and as you say, it is not 850C specific and is a good example of sharing the code.

[daenny]

Just revisiting some of these issues:

I would like docker based build environment. I am not that into embedded programming (yet), but being able do build inside a docker would mean that everybody can build the code without much trouble and the builds are the same, no matter if you compiled on windows, mac, or linux. Thus for me it would enable, that I can try out some changes myself. Now I am a bit hesitant as I have no experience on which stacks I would need to install, etc.

You can still use all your visual tools for code editing as the docker based compilation would be optional.

It does not cost anything to host a docker image on the docker hub (as far as I know)

Someone would need to create a dockerfile which contains the necessarry build dependencies and the to compile you would run a docker command.

For someone having all dependencies installed on his own system like you, you can still compile 'normally' as you did before.

[casainho]

@geeksville os busy on next months, let's see if someone other can do it

[wildekek]

I just built both LCD/Controller firmware on OSX and the only thing I needed was installing a few packages. I also think Docker itself could introduce a barrier to entry for people unfamiliar with it. Would you agree that expanding the wiki page to include OSX/Linux/Win build dependencies would suffice? If so I can write the OSX part this week.

[casainho]

Yes, there is space in wiki for such information, go ahead.

[coaxial]

Is anyone working on this? I’d be happy to look into it otherwise.