> From [email protected] Tue Jun 13 15:53 CDT 1995
> To: [email protected] (Marty Kraimer)
> Cc: [email protected]
> Subject: Re: Building for more than one host architecture
> Date: Tue, 13 Jun 95 16:53:01 -0400
> From: [email protected]
> X-Mts: smtp
> Content-Type> : > text>
> Content-Length: 395
>
> >But doesnt this mean that everytime an application developer
> >changes to a new application directory he/she has to make sure it is on the
> >same release or else has to type "setup epics3_12".
>
> I stand corrected: "." relative path is better for application developers.
> But I still prefer not using /usr/local/epics (which, after all, is a
> single version/release of epics just like $EPICS).
>
> Chip
>
Let me give some arguments why we want a directory such as /usr/local/epics
(again there is no magic about /usr/local. It could be any directory).
Each epics developer and each epics user has to have some definitions
(environment variables,etc) created for him/her. In addition there may
be additional release independent epics files needed. By creating a
directory /(something)/epics the only time the epics system manager needs
to interact with the unix system manager is to create the directory.
The owner of the directory should be the epics system manager. Only
release independent files should be placed in this directory. Again only
release independent definitions should be placed in this directory.
In order to use epics, the only thing user should have to do is place a
single command in his/her .cshrc (or similar file for other shells).
At aps this command is
source /usr/local/etc/Cshrc.aps
which happens to contain the command
source /usr/local/etc/setup/EPICS
By doing this the epics system manager can make changes to setup environment
without requiring all users to modify their .cshrc files.
An additional comment:
I think that we currently have quite good techniques for providing access to
multiple releases of base. Allowing users access to multiple versions of
extension products is not as convienent. See the EPICS S/R release manual
for current techniques. We had a lot of discussion on this topic but no one
could think of a "perfect" solution.
Marty Kraimer
- Navigate by Date:
- Prev:
Re: Building for more than one host architecture watson
- Next:
Re: application directories and CVS, GNU make etc Marty Kraimer
- 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 Marty Kraimer
- 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
|