xpack

[trampas]

Would it be possible to add xpack to install compiler and development tools. This would be huge advantage.

[github0null]

Any gcc is supported.

You just need to install xpack-arm-none-eabi-gcc on your computer and then setup the gcc path

[trampas]

I understand about setting up arm-none-eabi-gcc, so let me explain problem a bit more in detail.

I develop a lot of firmware for lots of projects, around 10 going at any given time. Each project uses a specific version of arm-none-eabi-gcc, cmake, ninja, build tools etc. xPacks basically allows you to setup a json file which specifies versions and tools used for each project independently. Here what you can do is issue the 'xpm install' and it will install the correct versions of development tools and provide symbolic links via the xpacks/ directory in you project. As such the EIDE project would need to pull the tools and such from this directory.

This is great but it also is only half the problem. The second part is handing off projects to other developers.

So now I have projects in github, a new developer clones the project to their local directory. Once they do this they need to install xPacks, VSCode, JLink software, etc. This problem is a lot more complex, and I have not found a good way to solve it other than create a batch script or something that will go download the tools and install them. Once they are installed then they need to run all the setup and configuration for the project. For example using xPack if the xpack directory does not exist then EIDE could detect this and run the 'xpm install' to install the correct development tools on first build.

Note that all this is so that the next developer can recreate a binary exact copy of embedded firmware that I created at anytime in the future. The reason for binary exact firmware is that a huge amount of development and testing has gone into each release, so changing compiler or tools where minor changes in code could change timing or expose other issues. Therefore we lock in tools such that we can replicate the tested and verify build at any point in the future.

[github0null]

I think I understand that you want the eide plugin to be able to parse the json generated by xpack to automatically select the compiler. Is that right?

Since I haven't used the xpack tool yet, I'll look into it first and if it's easy to implement, I'll add it.

[trampas]

Yes!

The idea is that in 5 years if someone downloads the project from git. Then they can run some very basic setup and on their computer they can build the firmware and get the same exact binary (hex, elf) results. Thus they need to run the same version of build tools (make, cmake, etc), the same build commands (makefile, etc), and use the same compiler, same compiler options, etc.

The best way to imagine this is that you are building a heart pacemaker. You find that compiler version 8.3 had a bug, so you replaced the code with inline assembly and have spent 6 months doing all the safety testing on the pacemaker. So you start shipping the pacemaker and a year from now a small bug is found. So you go to fix the bug, however in the mean time you have upgraded compiler to 9.4. Compiler version 9.4 had a bug that 8.3 did not, so you build product and if you just verify the small bug is fixed you will never find the new compiler bug.

To avoid these problems on mission critical embedded we keep the same build tools, compiler, etc. That way when we do incremental fixes we reduce the risks of introducing new bugs from the tool changes. We go as far as comparing binary outputs and verifying the changes to reduce the test time.

What this means for an embedded development environment is that it needs to use the same tools for the project that the was used when project was tested, regardless of which computer it is ran on or when it is ran.

In the ideal world we would have a json file like package.json used on xpacks (xpm) or node (npm) such that when you load the project you load the same build tools, same version of plugins, etc. Then everything about the project is stored in json files with project, for example the command line build options and compiler options.

As such we do testing where we build project in an IDE and generate binary outputs (hex,elf). Then we have other team members clone the code on their workstations and verify they can replicate results. Most of the time this limits us to creating our own makefiles and such in order that we can replicate the binaries.

Again this is not Arduino hacking, this is serious mission critical embedded work...

[github0null]

Thank you for your additional clarification