Re: EPICS_DB_INCLUDE_PATH

[Han Lee via Tech-talk <tech-talk at aps.anl.gov>]

Simon described clearly, and his explanation is excellent for e3, and that is my design concept for e3 also according to PSI experiences.

I don't know what the current policy of e3 has. But, the original policy which I designed was to convert all substitutes files to a single DB file during the installation procedure. So, a startup script only uses several DB files instead of any others. It allows users to use other formats, but no recommendation for this. All version controls for DB and substitutes files are in standard git version controls procedure. Different versions of each module and IOC will have different DB files for production and installation.

This policy, I believe, could remove these potential issues on the DB file versioning and substitution files.

I replied to this discussion because I don't think I explained this policy enough to Timo, Simon, or others at ESS. But everything was my original design and implementation.

HTH,

Han

On Thu, Dec 16, 2021 at 10:40 AM Ralph Lange via Tech-talk <tech-talk at aps.anl.gov> wrote:

On Thu, 16 Dec 2021 at 09:34, Simon Rose <Simon.Rose at ess.eu> wrote:

In e3, the database files that are installed with a module will always be installed at the location $(module_DB) (an environment variable set by require when loading a module).

In general the e3 team at ESS recommends referencing the database file paths explicitly as opposed to relying on or manipulating EPICS_DB_INCLUDE_PATH; given that there are many modules installed together, it seems you could end up loading the "wrong" one in a possibly annoying to trace way.

Similarly, if database files are located relative to the current startup command, it would be best to explicitly reference the file as

dbLoadRecords($(E3_CMD_TOP)/path/to/database.db)

so as to remove ambiguity.

The more problematic case are substitutions files: the name (and possibly full path) of the template database are inside the substitutions file, which itself could be under version control from a different shared support module...

Cheers,
~Ralph

--

Jeong Han Lee, Dr.rer.nat

Staff Scientist and Engineer

Lawrence Berkeley National Laboratory

1 Cyclotron Road Mailstop 46R0161

Berkeley, CA 94720, United States

Tel :+1-510-486-6163

Cell:+1-510-384-3868