Rework how CROSS_COMPILER_TARGET_ARCHS is handled

[JJL772]

This will be required for a unified build of base for PCDS and the accelerator. PCDS uses a different, smaller set of target architectures (RTEMS 4.7.1 and LinuxRT x86_64) in comparison to the accelerator (RTEMS 4.10.2, LinuxRT x86_64/Zynq/i686). Obviously we don't want to/can't build all of the acclerator target architectures on the PCDS side of the house.

We'll need to explore a way to manage CROSS_COMPILER_TARGET_ARCHS better.

Discussion in #7

From @bhill-slac:

bhill-slac commented Mar 13, 2024 via email
One more thought on this.

You could add a new target in base, something like all-targets.
When you're building base you use "make all-targets" and it builds all
supported ARCHS for that host.
When eco_tools builds releases, it uses "make all-targets".

During normal development, you just use "make" and if the IOC or module
needs to support any particular ARCH it can add it to
CROSS_COMPILER_TARGET_ARCHS.
Otherwise, it just builds for the host arch.

To implement this, the BASE  RULES* files would need to add the new target
and add some lines to clear CROSS_COMPILER_TARGET_ARCHS if MAKECMDGOALS
doesn't include all-targets.   I'm not sure just where this should go
but could look
into it if needed.

Note that support for all-targets would need to be added in the
slac-config-changes-vs-* BASE branches.
You'd also need to keep the existing lines in our
lcls-config-changes-vs-* and pcds-config-changes-vs-*
BASE branches that define the supported CROSS_COMPILER_TARGET_ARCHS for
each host arch,
so it wouldn't eliminate the need for different BASE releases for lcls
and pcds.

 bhill-slac commented Mar 14, 2024 via email
On 3/13/2024 11:51 PM, Bruce Hill wrote:
 You'd also need to keep the existing lines in our
 lcls-config-changes-vs-* and pcds-config-changes-vs-*
 BASE branches that define the supported CROSS_COMPILER_TARGET_ARCHS for
 each host arch,
 so it wouldn't eliminate the need for different BASE releases for lcls
 and pcds.
Or rework these lines so all our SLAC BASE branches define both
PCDS_CROSS_COMPILER_TARGET_ARCHS
and LCLS_CROSS_COMPILER_TARGET_ARCHS and the all-targets support determines
which to use when populating CROSS_COMPILER_TARGET_ARCHS based on
existence of /cds/group/pcds.

 bhill-slac commented Mar 14, 2024 via email
There may be a way to do this without adding all-targets.

We'd use the idea of having all SLAC BASE branches define both
LCLS_CROSS_COMPILER_TARGET_ARCHS and
PCDS_CROSS_COMPILER_TARGET_ARCHS
and automatically set CROSS_COMPILER_TARGET_ARCHS
for "make all".

This would give us essentially the same developer build experience as we
have now
in terms of which target ARCHS get built.

This wouldn't eliminate all the differences between the LCLS and PCDS
BASE releases,
but it could move most, if not all, of the cross compiler related stuff
to the slac-config-changes-vs-* branches.

 bhill-slac left a comment

This should work. Note that all cross targets get built on each host, although subsequent builds should be pretty fast as most of the compiled objects will be uptodate. You'll still need to run the host builds for rhel6, rhel7, rhel8, and rhel9 on different build hosts. Perhaps a good opportunity to use containers for each host arch so you could launch them all from one host.

From @ernestow:

 ernestow commented Mar 14, 2024 via email
Our goal is to use the same version of EPICS BASE for both PCDS and ACCL.

So, after we normalize the config related changes, then we go after source code chages.

We optimistically want to achieve this in a 7.0.8 or later release of EPICS going forward.

For 7.0.3 and 7.0.6 releases, separate release for ACCL versus PCDS is okay.  🙂

[marciodo]

Jeremy, why can't we have one single release of EPICS base that everyone can use?

Obviously we don't want to/can't build all of the acclerator target architectures on the PCDS side of the house.

Why do we need two sides in the house for EPICS base?

[JJL772]

The RTEMS toolchain used by PCDS is for RTEMS 4.7.1 and (apparently) doesn't work at all anymore. For the accelerator, EPICS 7 uses 4.10.2, and the way we specify the RTEMS version is in configure/os/CONFIG.Common.RTEMS-<arch>, which is tracked in git. There may be some other issues that I'm not aware of, next week I plan to meet with Mike Browne and others to try to understand the differences between the two versions of base.

Why do we need two sides in the house for EPICS base?

Well, my current goal is to figure out how to merge them for the 7.0.8 release. I don't think it's worth the effort trying to merge the existing 7.0.X releases at this point.

[marciodo]

That is assuming that we are going to have one tool chain for PCDS and another for EED. I'm thinking about how things will be in S3DF. The toolchains should be the same, too, I think. Yes, I'm always thinking on the future, not how to fix things that were already released.

[JJL772]

I agree with you on that. My only concern is recompiling the 4.7.1 toolchain...that thing is ooooold. GCC 4.1.1 from 2006.

[ernestow]

Yes, we should drop 4.7.1 PCDS no longer needs that RTEMS is basically gone on the PCDS side

On Mar 15, 2024, at 14:02, Jeremy L. @.***> wrote:



I agree with you on that. My only concern is recompiling the 4.7.1 toolchain...that thing is ooooold. GCC 4.1.1 from 2006.

— Reply to this email directly, view it on GitHubhttps://github.com/slac-epics/epics-base/issues/15#issuecomment-2000435438, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AB44BJCZDSWVMXBJ4HIFVLLYYNOW3AVCNFSM6AAAAABEYRFM6OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMBQGQZTKNBTHA. You are receiving this because you were mentioned.Message ID: @.***>

[JJL772]

From Bruce on #16

My general comment is that PCDS may need their own version of this change since I think they still have a few older RTEMS IOCs. Mike Browne may have a better idea of how many. Also, see $CONFIG_SITE_TOP/common_dirs.sh for a different take on how to handle these differences in where packages and other common directories are located. I think the RTEMS builds still had hard coded paths as they pre-dated my introduction of common_dirs.sh into eco_tools so it could work in different environments including LCLS, PCDS, ACCL, PAL, etc, and we were already phasing out RTEMS in PCDS.

+1 for this idea.