What Janet is proposing looks OK except that not all sites install
their extensions in /usr/local/"whatever", or use the script that APS
does. Some sites build the extensions alongside base and then use an
extension link in their boot directory just like the base link. THe
reason for this is that an IOC and/or sub project can be on a different
release of EPICS and still work. For example, here at LBL we have
projects running on R3.7, R3.11, and at one project both R3.11 and
R3.12Beta. If the EPICS extensions were in /usr/local or some other
global place then it would be harder for application developers that
have to move across projects to be setup correctly.
What might be a better idea is to have 2 different environment scripts
that could be used. One sets up for /usr/local (or other global path),
the other sets up for a path the same as base.
One script would do this:
./base/bin/$HOST_ARCH
./base/tools
/usr/local/epics/extensions/bin/$HOST_ARCH
The other script would do this:
./base/bin/$HOST_ARCH
./base/tools
./extensions/bin/$HOST_ARCH
Or we could just let the Site pick their method of making sure
$HOST_ARCH got set correctly.
Mike B.
- Navigate by Date:
- Prev:
Re: application directories and CVS, GNU make etc Rozelle Wright
- Next:
Re: Building for more than one host architecture Ric Claus
- 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
- Navigate by Thread:
- Prev:
Re: Building for more than one host architecture watson
- Next:
Re: Building for more than one host architecture Ric Claus
- 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
|