Re: EPICS_BASE smart definition

["Konrad, Martin via Tech-talk" <tech-talk at aps.anl.gov>]

Hi Dominique,
> On our site we used to have only one EPICS base with supports linked on.
> 
> The goal is to install few EPICS releases on site with a smart approach.
> The goal is at the end, to containerise(?) each application.
Sounds like you want to pick one of these two approaches. If you
containerize your IOCs each container only needs to contain one version
of EPICS Base. If you want to upgrade, you stop the old container and
start a fresh one built with the new version of EPICS Base. (Keep the
old one around for a while in case you need to roll back.)

> EPICS_BASE:=$(shell echo ${EPICS_BASE})
A potential problem with this is that you might be modifying a file
which is under revision control. It's easy git revert this change by
accident. Ralph's CI scripts generate a RELEASE.local file which only
contains autogenerated stuff and doesn't even need to be in the checked
out source directory (it can live one level above). He simply includes
it by appending

-include $(TOP)/../RELEASE.local
-include $(TOP)/../RELEASE.$(EPICS_HOST_ARCH).local
-include $(TOP)/configure/RELEASE.local

to the end of the existing static RELEASE file. More and more modules
already come with these lines [1,2].

Hope that helps,

Martin

[1]
https://github.com/epics-modules/asyn/blob/master/configure/RELEASE#L19-L21
[2]
https://github.com/epics-modules/motor/blob/master/configure/RELEASE#L47-L49

-- 
Martin Konrad
Facility for Rare Isotope Beams
Michigan State University
640 South Shaw Lane
East Lansing, MI 48824-1321, USA
Tel. 517-908-7253
Email: konrad at frib.msu.edu