Multiple architecture support #32
Description
Intro
We would like to support:
- multiple host architectures (at least linux/amd64 and linux/arm64)
- multiple target architectures
The first of the above is a build-kit supplied build arg and should be used to set what the EPICS_HOST_ARCH looks like.
The second should be used to control the EPICS_TARGET_ARCH.
Each value for EPICS_TARGET_ARCH should result in a separate runtime/developer container pair in the registry.
For the simpler cases, the HOST and TARGET are the same but we also want to support cross compilation to other architectures such as RTEMS (but RTEMS can itself have many target architectures). I expect that all cross compilation will be done from linux/amd64 (==x86_64) host.
Current Status
At present the names epics-base-rtems-runtime and epics-base-linux-runtime are inadequate to cover all possibilities. These two have (EPICS) target architectures respectively:
- rtems-beatnik
- linux-x86_x64
And hence their names are not really representative.
The Good
Because epics-base-linux is the host architecture and extremely common I vote for keeping this name - partly because it would be a massive breaking change. But also this is OK because:
- changes to the host architecture would be handled transparently by build-kit
- hence pull
ghcr...epics-base-linux-runtimewould get you an arm64 or x86 image, based on your workstation architecture (or override with--platform)- e.g.
pull ghcr.io/epics-containers/epics-base-linux-runtime:7.0.8ec1b2 --platform linux/amd64
- e.g.
What needs fixing
However we should change epics-base-rtems to epics-base-rtems-beatnik to reflect the target arch correctly. In addition we should:
- Update the structure of the Dockerfile stages to support multiple target architectures (at present it is just host and rtems effectively)
- Have the new structure determine new target names - this might be challenging and might require a new (one liner) stage per new target arch - Which is OK as long as we have a mechanism for expanding on our future targets
- For RTEMS (and any other target groups) we would need to make a new BSP for the specific board and break up the rtems6-powerpc project into the same target arch stages. (and this implies that rtems-powerpc is the wrong name in the future)