1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 <2019> 2020 2021 2022 2023 2024 2025 | Index | 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 <2019> 2020 2021 2022 2023 2024 2025 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Re: How to pick up value of environment variable in /configure/RELEASE? |
From: | Michael Westfall via Tech-talk <[email protected]> |
Cc: | "[email protected]" <[email protected]> |
Date: | Wed, 16 Jan 2019 17:01:10 -0300 |
Hi Mike,
On 1/15/19 7:57 PM, Michael Westfall via Tech-talk wrote:
> For example, if I currently have:
> EPICS_BASE=/my_epics_location/epics/R3.14.12.7/base
>
> but I want to be able to change the location of /my_epics_locationon
> the fly (perhaps because I want to use a different version of EPIS)
> by setting an environment variable $MY_EPICS_LOCATION,
>
> then how would I pick up the environment variable value in
> configure/RELEASE?
>
> I feel like I should know this, but I guess I haven't ever had reason
> to do it before.
The basic EPICS build system was designed explicitly to *not* take
RELEASE paths from the build-time environment, as that makes the build
process potentially unrepeatable. At the APS and many other sites we
expect to be able to revert our operational IOCs to an older version
that might depend on different support modules just by checking out the
files for that version of the IOC and running 'make'. Any EPICS
developer should also be able to replicate a build the same way
irrespective of their current environment, but this wouldn't work if
environment variables could override the settings in the RELEASE files.
You can define and use variables in your RELEASE files and even include
other files, but you would still have to modify at least one line of one
file to switch to a different Base version (and change the paths for any
other dependent modules at the same time). Synapps includes a
configuration management system that modifies RELEASE files, and BESSY
publish a tool called SUMO which can check out and build a complete set
of dependent modules for you, including reusing any modules that have
already been built for the desired configuration.
Other sites have developed alternative approaches and made local changes
to the code for their approach to builds, but I don't think the current
approach is likely to be changed in the EPICS core build system
until/unless someone else takes over maintenance of it.
- Andrew
--
Arguing for surveillance because you have nothing to hide is no
different than making the claim, "I don't care about freedom of
speech because I have nothing to say." -- Edward Snowdon