Multiple architecture support

[gilesknap]

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-runtime would 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

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)

[gilesknap]

@coretl for comment

[gilesknap]

I should also say that windows will be a special cross compile.

Target name probably:
epics-base-windows-runtime

[coretl]

Target name probably: epics-base-windows-runtime

How about this as a naming scheme:

• Linux is the only platform where the runtime platform actually executes the binary, therefore naming it epics-base-linux and using the build-kit platform to differentiate between arm64 and amd64 seems correct
• Windows and RTEMS binaries are only hosted by the runtime platform, so the build-kit platform of the runtime doesn't make any difference to the binaries. I suggest we name them the same as the EPICS_TARGET_ARCH, so epics-base-rtems-beatnik and epics-base-windows-x64

[gilesknap]

I approve that choice.

[gilesknap]

leaves epics-base-win32-x86-static as an option 😟