Experimental Physics and
Industrial Control System

The stacks are considered separate packages and I hope they can be built
independently and installed side by side under the BSP. From an RTEMS
perspective if a stack (or any 3rd party package) can be built I would prefer
that happens so users can select which ever stack they want using options or
configurations they have control over.

Can the EPICS build system check the BSP to see which libraries are present and
then decide which stack to use? The libbsd library is libbsd.a and I am not sure
what the net-legacy archive name is.

How do you reconcile those two: If both stacks can be built for a BSP, both sets of libraries would be present, so checking for the presence of one or the other library wouldn’t tell us which to use.

We don’t currently have a way in EPICS to adjust what we build based on what libraries are available upstream, although that could be added if necessary. The user needs to specify that kind of thing somewhere, but I think we’d prefer that the RTEMS BSP tell us how it has been configured in the makefile fragments that we include from the BSP. If the user has to provide information about how the RTEMS BSP was built in their EPICS build configuration but they get it wrong our code will fail to build, so it seems more sensible for our build system to get as much information as it can directly from your build system.

If you get to the stage were a user can have both stacks built and installed so that switching between them would just be a matter of user preference when EPICS gets built, then letting the user choose the stack in their EPICS target configuration would be fine, but we’d want to be able to confirm that their RTEMS build actually contains the stack they’re asking for at the start of our build, not when we first try to compile or link an application image against it.

- Andrew