Experimental Physics and
Industrial Control System

[email protected] (Marty Kraimer) · Wed, 14 Jun 1995 08:12:25 -0500

> 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

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System