> From [email protected] Tue Jun 13 12:25:35 1995
> Return-Path: <[email protected]>
> To: [email protected]
> Cc: [email protected]
> Subject: Re: Building for more than one host architecture
> In-Reply-To: Your message of "Tue, 13 Jun 95 14:10:50 EDT."
> <[email protected]>
> Date: Tue, 13 Jun 95 13:24:51 -0500
> Content-Length: 322
> X-Lines: 10
>
>
> >I'm not fond of installing code in /usr/local. Assume that EPICS is installed
> >in the path $EPICS, then add the following to everyone's path:
>
>
> I'm not fond of environment variables. Let's please assume that EPICS
> is installed relative to ~epics instead. If you really want $EPICS,
> then, set it using ~epics.
>
> --John
>
As a LANL AOT-8 EPICS consulting, training type person,
I've been doing a lot of traveling recently.
At the last 4 places I've been only one of them still has current epics code
in the ~epics directory. I think this is because ~epics has to
be set up by the system manager and epics management is done by different people.
As my contribution to this topic, let me say that I don't care about the details,
but keep the following in mind:
For people setting up new applications it should:
1. Be easy for new users to set up -- EPICS is expanding rapidly and people don't
always know what their full system will look
like when they first start. Getting a quick
start to a working application is important.
2. Be possible for other people than the developers to modify
or customize for their own use.
I think making it use the EPICS CONFIG files should help with this.
I am positive that one method of application environment setup will not
work for all applications. Keep it flexible!!
3. Not be dependent on tools that aren't distributed with EPICS.
We don't have the "setup" tool here at Los Alamos.
Perhaps it should be distributed with EPICS if that is the way people
decide to go.
For people working with the development of several applications it should:
1. Be possible to move from one application to another without having to modify
paths. This is possible now with the current way that getrel
does relative paths, except for the extensions directory.
2. Be possible to get a new release of EPICS without a great deal of work.
This is complicated now, because of having to recreate databases and also
redo makesdr if we have local records and devices.
It should be helped greatly if we go with the ascii definitions of databases.
3. It should be easy to track changes in applications. This one isn't easy yet.
Keeping track of changes to databases and displays is hard.
When William and Nick have a Beta version working I would be interested in trying
it out.
Rozelle
---------------------------------------------------------
| |
|Rozelle Wright Phone (505) 667-4804 |
|Los Alamos Natl Labs AOT-8 FAX (505) 665-5107 |
|PO Box 1663 MS-H820 Group Office (505) 667-6087|
|Los Alamos, NM 87545 email : [email protected] |
| |
---------------------------------------------------------
- Navigate by Date:
- Prev:
Re: Building for more than one host architecture watson
- Next:
Re: Building for more than one host architecture Michael Bordua
- 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: application directories and CVS, GNU make etc Marty Kraimer
- 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
|